Date: Tue, 14 Nov 1995 22:21:56 +0800 (WST) From: Peter Wemm <peter@jhome.DIALix.COM> To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= <ache@astral.msk.su> Cc: davidg@Root.COM, committers@freebsd.org, security@freebsd.org Subject: Re: cvs commit: CVSROOT log_accum.pl Message-ID: <Pine.BSF.3.91.951114220712.4688H-100000@jhome.DIALix.COM> In-Reply-To: <eshz9gm4G1@ache.dialup.demos.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 14 Nov 1995, =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > In message <199511131630.IAA04150@corbin.Root.COM> David Greenman > writes: > > >>>>Peter, do you have any progress in this issue for now? > >>>>Maybe it is time to commit my fix to -current? > >> > >>> If we decide to change setlogin() so that it only works for session > >>>leaders, then I'd prefer that we leave out the printf(). If you want to add > >>>that to your own sources, fine, but I prefer to keep console noise minimized > >>>to important failures. > >> > >>Of course. Printf introduced by Peter, I mean "return (EPERM);" here > >>not a printf. I refer on my original fix and not to quoted variant > >>from Peter. Setlogin must affect only _current_ session as clearly > >>said in manpage (and from common sense), so no doubts here. > > > The current behavior is not inconsistent with the manual page. It says > >nothing about a requirement that the session *leader* must be the caller, > >only that it affects the current session. > > Yes, but if it isn't leader, it affects *all* sessions, not current one > only, it is main bug. No.. it's not _that_ bad.. Suppose you have the case of the original rshd, it forked itself, and the child process did the setlogin(). Since inetd is now starting all processes in their own session, the parent rshd is the session leader and the child is not. The rshd would fail under your proposal even though (in this case) it's a valid operation. The child's setlogin() would affect both the child and the parent. I've since "fixed" rshd so that the parent does the setlogin() - the only remaining program that is broken that I am aware of is XFree86. > As manpage additionly says, it happens "only when new session is > being created", it assumes session leader too. > > I think we need to ask someone from BSD group, what they > keep in mind exactly on this thing. Can you contact such person, please? The original implementation in 4.3BSD (or one of the -net releases) apparently the login name stored in the user struct and had it being strictly inherited from parent to child like setuid(). Somewhere along the way, it seems to have changed semantics to something that is somewhat "non-obvious". (witness the confusion about how to use it in all the code.. even 4.4BSD itself was not compatable with it's own semantics). I still think we should move the login name to the "struct ucred" - then the possibility of the entire session being accidently changed would no longer be an issue. struct ucred is normally 76 bytes long now. Another 12 bytes wouldn't hurt all that much... (especially since another transient data structure would shrink as a result to partly offset the cost). IMHO, having a child process being able to modify the parent's environment goes against the unix religion^H^H^H^H^H^H^Hphilosophy of inherited privilege. Cheers, -Peter > -- > Andrey A. Chernov : And I rest so composedly, /Now, in my bed, > ache@astral.msk.su : That any beholder /Might fancy me dead - > http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. > RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.951114220712.4688H-100000>