Re: launchd daemon, spawning children?
Re: launchd daemon, spawning children?
- Subject: Re: launchd daemon, spawning children?
- From: Terry Lambert <email@hidden>
- Date: Fri, 26 Sep 2008 16:33:57 -0700
On Sep 26, 2008, at 2:37 AM, Mario Emmenlauer wrote:
Damien Sorresso wrote:
The rules of setuid(2) have evolved into a vastly complex morass
with subtle variations on different platforms. Entire papers have
been written about this behavior.
You name it. I will look for a good tutorial, though Terry's
suggestion
contained a nice start.
The kernel interfaces are not really vastly complext; most of the
complexity is in user space session setup and teardown, which you
mostly do not have to care about if you write "UNIXy code".
The primary paper on UNIX setuid() is:
Setuid Demystified
Hao Chen, David Wagner, Drew Dean
Proceedings of the 11th USENIX Security Symposium
<www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf>
The main difference between Mac OS X and POSIX standard behaviour is
that we support external group resolution for group membership above
and beyond the default list of the effective group plus 15
supplementary groups (the 0th supplementary group is a synonym for the
effective group, for a total of 16 in the array for getgroups()/
setgroups(); this is an historical BSD thing, permitted, per POSIX).
You can initialize this using initgroups(), or you can use
syscall(SYS_initgroups,...), which takes the same arguments as
setgroups(), plus a uid argument as the key for looking up group
membership for the groups served through DirectoryServices.
A secondary difference is in per-thread credentials, which inverts the
group list and uid set ordering. In per thread credentials, you
initialize the group list last; this is permissible since you cannot
set them except from a privileged process, and they are being used for
proxy operations, usually by a file services dameon, and are not
security sensitive. Since the initial privileged process that started
the thread within itself (1) has a still-accessible heap and stack
after the change and (2) has the rights to set grouplist - and
resolver uid membership - anyway, on a process-wide basis, permitting
setting this in a thread running under an assumed credential does not
decrease security.
-
In general, we do not want you to establish your own sessions, and
would prefer that you use /bin/login to do session management and
support the utmp/utmpx interfaces for process accounting and knowing
who is logged into your system, etc.; otherwise, things get more
complicated fast, in order to support those interfaces, since you have
to (1) maintain privilege in order to access the files to write out
the closure records on sessions started by you (login does this - it
hangs around until its children go away), and (2) deal with PAM and
all the other things login deals with for authenticating you to the
system.
-- 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