On Sun, Apr 27, 2003 at 04:49:53PM +0100, Colin Watson wrote: > > On the non-linux ports: note that priviledge separation is not supported > > on GNU, and will probably never be, since it has a different concept of > > user priviledges. > > I don't understand why. Privilege separation just requires a separate > user and group which is used for processing network data, the ability > for sshd running as root to setuid(), setgid(), and setgroups() to that > user and group, and an empty chroot. I didn't think GNU was so different > that this would be unavailable; in fact, I would expect all of these > features to be available on any Debian system. The reason why privilege > separation doesn't work on Linux 2.0 was originally due to the lack of > anonymous memory mapping, and now that that has been worked around it's > due to a simple bug (#150976). > > Could you please explain the problem on GNU in more detail?
Neal just explained what i meant. Priviledge handling is one of the typical features that come out when trying to explain GNU's system core (Hurd/Glibc) dessign. [*] I assumed that Priviledge Separation was some kernel-specific feature introduced with Linux 2.1 that probably wasn't worth implement. but as you describe it seems simple. maybe we could have it to keep openssh happy Last time i tried, sshd failed to initialise a session on GNU with PrivSep turned on. did you mean a PrivSep special API needs to be added, or is sshd suposed to work on any sane (unlike this one ;)) system? [*] I just want to add that process spawning and priviledge scalation don't necessarily correspond to the same program. A shell daemon could just happily spawn a shell with no priviledges (unidentified user) to everyone that requests it (without authentification). then the "login" utility could add priviledges to him/her, no matter where he/she comes from, just as it does with the users in local terminal. -- Robert Millan make: *** No rule to make target `war'. Stop. Another world is possible - Just say no to genocide
