Re: launchd daemon, spawning children?
Re: launchd daemon, spawning children?
- Subject: Re: launchd daemon, spawning children?
- From: Terry Lambert <email@hidden>
- Date: Thu, 02 Oct 2008 09:59:02 -0700
On Oct 1, 2008, at 10:30 PM, Kevin Van Vechten <email@hidden> wrote:
On Oct 1, 2008, at 12:21 PM, Terry Lambert wrote:
You probably actually want:
setgid();
syscall(SYS_initgroups, int ngroups, const gid_t *gidset, uid_t
gmuid)
Calling initgroups(3) is a better idea. It's not recommended to
make syscalls directly. Doing so might not be compatible with
future releases of Mac OS X.
Kevin is of course right about this. But it adds substantially to the
complications I was trying to avoid explaining before.
The parameters for initgroups(3) have a string name, which requires
using getpwuid(3) to convert the uid into a string name so the
initgroups(3) can call getpwnam(3) to convert the string name to a uid
so it can call the SYS_initgroups call under the covers. There is a
fundamental assumption that the two "get" calls will be reflexive for
any directory service; that is, a given name does not map to more than
one uid, and a given uid reverse maps to only one name. As an
implementation detail, the SYS_initgroups itself could end up changing
or going away entirely.
By taking the string name, it also takes the decision of what
supplementary groups other than the primary group will be in the list
if 16 out of your hands and gives it to libinfo which gives it to
Directory Services. These are in turn the ones which get proxied over
the wire for certain network filing protocols, e.g. NFS, and if the
server side does not support external group membership resolution
(e.g. NetApp filers, or clients in a firewall DMZ talking to a server
interior to the firewall between the DMZ and "inside"), or does but,
is not a member of the same security association as the one granting
the credential via libinfo (including group initialization by the
initgroups(3) call), then you can lose on the reordering from the
indirect call. This is particularly true if the server is doing the
access control enforcement on a file or container object based on
group rights and group ID, and it's not your primary effective group
at the time of the call (you would potentially be denied access).
On top of this, we also reserve the right to change the little dance
programs must do to establish sessions from a Minuet to a Foxtrot or
The Froog at some point in the future. For interactive sessions, we've
thrown all our eggs in the login basket. For non-interactive sessions,
like user space network file services daemons, we've had to put the
knowledge into the server directly, or punt back to straight POSIX.
The flip side is that if you limit yourself to putting users in
NGROUPS only, traditional POSIX semantics apply, but you lose the
functionality of extended groups lists and of groups of groups that
you get by participating in external group resolution.
As I said before, it gets complicated.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden