Date: Thu, 1 Oct 2015 15:02:21 -0700 From: Bryan Drewery <bdrewery@FreeBSD.org> To: Jilles Tjoelker <jilles@stack.nl> Cc: freebsd-arch@FreeBSD.org Subject: Re: login -f changing session getlogin(2) Message-ID: <560DAD6D.7050007@FreeBSD.org> In-Reply-To: <20151001203436.GA22737@stack.nl> References: <560D826D.7000302@FreeBSD.org> <20151001203436.GA22737@stack.nl>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On 10/1/2015 1:34 PM, Jilles Tjoelker wrote: > On Thu, Oct 01, 2015 at 11:58:53AM -0700, Bryan Drewery wrote: >> This issue has bothered me forever. > >> As root running 'login -f someuser' and then exit, logname(1) and >> getlogin(2) will forever return that user's name, rather than root. > >> The issue is that login(1) uses setlogin(2) without ever restoring the >> login from the parent when it exits. > >> This is easily fixed by something like: > >> [snip] > >> I'm not sure this is the right way though. > >> My initial instinct was to use setsid(2) in the child but that clobbers >> the terminal. > >> It makes me wonder if there's bigger architectural issues here that need >> addressing with session and login. Perhaps login -f is just a special >> case though. > > I don't think login -f should be used like that. For that use case, su > -l looks more appropriate. In either case, the two login sessions are > strangely intertwined. Using ssh to localhost provides two normal login > sessions. > > Resetting the login name also affects processes started by the logged in > user that still run (as long as they have not created a new session). > This may confuse applications and hinders traceability. This breakage > would also affect normal login sessions on terminals. > > I think the supposed use case for login -f is a remote login daemon that > handles authentication by itself but wants to delegate account and > session functionality. Indeed, sshd has UseLogin, but it is rarely used > and discouraged. > Well, none of that is documented or its use discouraged. It has been quite surprising, for example, to find mails sent as the wrong user weeks after doing a 'login -f' out of habit from root. Can't we use something like forkpty(3) for the child to avoid the issues you mention? It calls setsid(2) via login_tty(3). And actually, 'su -l' NOT calling setlogin(2) is another surprise. I have used 'login -f' precisely because it simulates a real login and sets up the environment as the user. If I am dropping into a user's shell I expect things like 'mail' to have their FROM not root or wherever I came from in my session. -- Regards, Bryan Drewery [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJWDa1tAAoJEDXXcbtuRpfPNCsIAK31zYGtil31ajCYPdIMiu+O zoYefgi23feBtNSMIDygm2ypPCu+0ShKG8akwjfRVRGFgZD8nDMT9CViDX2NAsVV 0AqBSKL5CiGZPgFxL7wSF24G9sCFT3c6cGevAZ6+k7a/Sh81St/DVkL4S04h6Sh0 Wbvu+9GnfoUM9cMs9ze6o3vvMLyB63GdckTfJ5rs+daVcfyFzfodTvyBp3UbcEHQ ZJXcDRrfSb9a0Tt3WkHVEHzF55fe/NJKImFz9YR7FbZt3kOMCE8LvsMNUMbfBZ0y gFwr6Zuo8tQs9K5yvNVi/EURpD1rydFAyH8hbP/WMapXjylIsSM46lB+DXTkKW4= =ARdx -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?560DAD6D.7050007>