On Fri, 8 Jan 1999, Nick Maclaren wrote: > This isn't pedantry - it is a real problem. > > Consider things like job schedulers, printing systems and so on. User > A calls one of those, which runs as user B. It then calls mail - the > examples were chosen because both of them do precisely that. Which > is the user identification that the mailer should use? > > There are many possible 'solutions', but none are satisfactory. For > example: It would seem like one possible solution would be to treat setuid like a directory structure, so could build "absolute" setuid "paths". getuid() would return either the real id of the current process, or the list (array) of real ids back to the "root" (the one owned by root, not the first process) process (like the directory structure has a root at /). I think this could be set up in the Unix kernel to operate seamlessly in the way that setuid/getuid normally work, but also allow extended functionality for better process security. I think this would only require minor modifications to the process table (replace the uid/gid piece of the task structure with a pointer to a list of uid/gids). So instead of getuid() returning current->uid, it would return current->uid->uid, for example. Looking at the Linux kernel code, it doesn't look like this would be incredibly difficult to do. Of course, any programs that want to use the extended functionality of getuid() would have to be rewritten. And I'm probably overlooking a hundred details... Pete Kruckenberg http://pete.kruckenberg.com/resume/
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:28:19 PDT