login -f changing session getlogin(2)

[Bryan Drewery]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20151001/0a84f767/attachment.bin>