site_archiver@lists.apple.com Delivered-To: Darwin-dev@lists.apple.com User-agent: Thunderbird 2.0.0.17 (Macintosh/20080914) Hi Terry and List, You name it. I will look for a good tutorial, though Terry's suggestion contained a nice start. 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> Thanks a lot, the paper is great! I finally ended up with something like (pseudocode): fork(); if(pid == 0) { setgroups(); setgid(); setuid(); close_nonstd_file_descriptors(); execve("/path/to/worker"); _exit(); } else { while(1) { waitpid(WNONBLOCK); usleep(1000); } } This works very well, and makes sure the worker process can not gain higher permissions than it should have. Don't mind the while(1) above, in practice I have a network connection open between worker and server to get error-feedback, so the server won't get stuck. Your suggestion to use login seems reasonable. Can someone sketch an outline how an application (daemon) would use login to start a new process as a certain user? Is that what you meant: execve("/bin/login -f worker_user /path/to/worker") One last question: If "worker_user" is the current GUI-user, all his applications get killed on logout. Is there a way around this (or would using 'login' also solve this issue?) Thanks again, Mario Emmenlauer _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... Terry Lambert wrote: 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. 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. This email sent to site_archiver@lists.apple.com