Date: Thu, 1 Oct 2015 22:34:36 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: Bryan Drewery <bdrewery@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: login -f changing session getlogin(2) Message-ID: <20151001203436.GA22737@stack.nl> In-Reply-To: <560D826D.7000302@FreeBSD.org> References: <560D826D.7000302@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151001203436.GA22737>