Is there something like the Linux specific SCM_CREDENTIALS unix(7)
socket "ancillary" message?

I have a root process that will be executing specific functions on
behalf of less privileged worker processes. The worker processes are
forked from and tracked by the root process but I would like to add
additional insurance that a worker will not be coerced into requesting
an operation that it should not have the privilege to do. I was excited
when I recently heard about SCM_CREDENTIALS because it would permit me to
write a "supercall" to a unix(7) socket and know for certain the uid, gid,
and pid of the caller. I could then check that against an access control
table. Unfortunately I only just now see that it is a Linux specific.

How can I do that portably?

Thanks,
Mike

[ Post a follow-up to this message ]

Michael B Allen <mba2000@ioplex.com> writes:
quote:

>Is there something like the Linux specific SCM_CREDENTIALS unix(7)
>socket "ancillary" message?

quote:

>I have a root process that will be executing specific functions on
>behalf of less privileged worker processes. The worker processes are
>forked from and tracked by the root process but I would like to add
>additional insurance that a worker will not be coerced into requesting
>an operation that it should not have the privilege to do. I was excited
>when I recently heard about SCM_CREDENTIALS because it would permit me to
>write a "supercall" to a unix(7) socket and know for certain the uid, gid,
>and pid of the caller. I could then check that against an access control
>table. Unfortunately I only just now see that it is a Linux specific.

quote:

>How can I do that portably?


Unfortunately, you can't; the only thing you can portably send is
a filedescriptor.  So what you could do is generate a file which is
mode 600, owned by the supposed caller and then challenge the caller
to send you the file descriptor.

BSD has SCM_CREDS which is similar to SCM_CREDENTIALS (and I think
Linux is moving to that structure)

If you'd want to stay nonportable, then many OSes have their own
mechanisms but they all work on different transports
(Solaris has always had "TL_OPT_PEER_CRED" which works for TLI loopback
transport; and it also has "door_cred" and uses the former to
provide a proper credential for loopback RPC but only using
undocumented interfaces).

In the next Solaris release, we've extended the number of places
were it's possible to obtain the caller's credential and have reduced
the number of different userland representations of the kernel
credential to just one (I think we had three).
(In Solaris, we've chosen to make the credential representation an
opaque blob of unfixed size)

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]