sendrec - call denied

[Kenneth Jacker]

Ben Gras wrote:
> Well, if you start it using the 'service' command, it IS a new
> server like FS, PM, DS or RS, it won't have a fixed process number
> (ipc destinations are called 'endpoints' nowadays) you can
> sendrec() to though, that's the only difference.

I have taken the above approach (rather than modifying entries in the
kernel), but am having a problem ...

When I contact my "server" by calling the 'sendrec'() function in
another "regular" (i.e., "user") program, the function returns an
error code:

ECALLDENIED/104 No permission for system call

Is there something else I need to do within my "server" and/or when I
start it using 'service'?

Thanks for your help/comments!
--
Prof Kenneth H Jacker k...@cs.appstate.edu
Computer Science Dept www.cs.appstate.edu/~khj
Appalachian State Univ
Boone, NC 28608 USA

[Ben Gras]

All,

(This is a copy of an email I had already sent to Kenneth.)

On 2007-03-18, Kenneth Jacker <k...@be.cs.appstate.edu> wrote:
> Is there something else I need to do within my "server" and/or when I
> start it using 'service'?

Ah, you've run into a "flexibility shortcoming" in the way ipc
permissions are controlled.. That's hardcoded in kernel/table.c
to be this:

#define USR_M (s(PM_PROC_NR) | s(FS_PROC_NR) | s(RS_PROC_NR) | s(SYSTEM))

So by default, regular processes are only allowed to talk to those processes.

To let regular processes talk to your server, RS would have to be taught to
tell the kernel that it's allowed, or you'd have to change the USR_M above to
allow all processes, or you'd have to include it in the image after all and
give it a fixed process number that you can include in USR_M.

I don't think it can be done in a stock Minix without changing the kernel.

=Ben