Peter Tribble wrote: > > > It would mean different users for every piece of software we integrate. > > and unnecessary administrative overhead for these. Is this useful > > enough to justify it? > > Definitely.
Yes, definitely. The primary reason for not running every daemon as root is isolation. Once upon a time most things ran as root. As soon as you managed to get any of them to do something unintended (by any number of ways), it did it as root, game over. Ok next we ran them all as some non-user (and "nobody" is a popular, if incorrect, choice). That's better, since the compromised process only gets limited access to do harm. Of course, if every important server (and its log files, data files, etc) on the system belong to that same user, the harm to be done isn't so limited after all. The logical conclusion is you run every server as its own user to isolate each one. That's how it works on e.g. debian - every (or so, I haven't checked all) package delivering a daemon process delivers a unique user to go with it. (Today there's more choices, zones for instance. But not everybody wants to always have to do separate zones for every thing. And while relatively lightweight, it is still more overhead (resources and administrative) than just running two processes.) > > What are the chances of having different types of databases running on > > the same system? _and where the administrator of both has to be different_? I don't follow the second question... There's no relation to who the admin is. The system uids are for the processes, not for humans. No person logs in as 'webservd'. > > The same holds true for other server software too, like webservers (we > > are integrating apache and lightd, and we are going with webserverd as > > the user for these.) That's a bug. The hassle today is that the users are embedded into the core OS instead of the package where it belongs. Once the packaging is able to deliver the user it needs, it'll be easy to fix them all. (Follow http://defect.opensolaris.org/bz/show_bug.cgi?id=217 for progress on that.) -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
