Skip site navigation (1)Skip section navigation (2)
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>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--61OirB5TTt3m23TUFLQbPuFDolenGrRRH
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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.
>=20
>> As root running 'login -f someuser' and then exit, logname(1) and
>> getlogin(2) will forever return that user's name, rather than root.
>=20
>> The issue is that login(1) uses setlogin(2) without ever restoring the=

>> login from the parent when it exits.
>=20
>> This is easily fixed by something like:
>=20
>> [snip]
>=20
>> I'm not sure this is the right way though.
>=20
>> My initial instinct was to use setsid(2) in the child but that clobber=
s
>> the terminal.
>=20
>> It makes me wonder if there's bigger architectural issues here that ne=
ed
>> addressing with session and login. Perhaps login -f is just a special
>> case though.
>=20
> 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.
>=20
> Resetting the login name also affects processes started by the logged i=
n
> 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.
>=20
> I think the supposed use case for login -f is a remote login daemon tha=
t
> handles authentication by itself but wants to delegate account and
> session functionality. Indeed, sshd has UseLogin, but it is rarely used=

> and discouraged.
>=20

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.

--=20
Regards,
Bryan Drewery


--61OirB5TTt3m23TUFLQbPuFDolenGrRRH
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----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-----

--61OirB5TTt3m23TUFLQbPuFDolenGrRRH--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?560DAD6D.7050007>