From owner-freebsd-arch@freebsd.org Tue Oct 27 22:13:36 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40A5FA1F0DE for ; Tue, 27 Oct 2015 22:13:36 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 09D5A177C; Tue, 27 Oct 2015 22:13:35 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 8067A358C5F; Tue, 27 Oct 2015 23:13:32 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 3A46028494; Tue, 27 Oct 2015 23:13:32 +0100 (CET) Date: Tue, 27 Oct 2015 23:13:32 +0100 From: Jilles Tjoelker To: Bryan Drewery Cc: freebsd-arch@freebsd.org Subject: Re: login -f changing session getlogin(2) Message-ID: <20151027221332.GA65001@stack.nl> References: <20151001203436.GA22737@stack.nl> <560D826D.7000302@FreeBSD.org> <201510012121.t91LLJ9h025117@hergotha.csail.mit.edu> <5627C5D4.6090203@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5627C5D4.6090203@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 22:13:36 -0000 On Wed, Oct 21, 2015 at 10:05:24AM -0700, Bryan Drewery wrote: > On 10/1/2015 2:21 PM, Garrett Wollman wrote: > > In article <20151001203436.GA22737@stack.nl>, jilles@stack.nl writes: > >> 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. > > Historically, as I remember it, "login" was a shell built-in that was > > effectively an alias for "exec login". It may still be that way in > > antique csh. The assumption from time immemorial is that if login > > exits, the parent process will not distinguish it from any other > > logout, so login is permitted to overwrite persistent session state. > Yes, if 'login' always exited the parent too then it would not be a problem. > If we're making that assumption though then why do we so carefully > handle setting up the user context, uid and pam sessions in the child? The parent login(1) process needs to stay around with root privileges to clean up PAM and update utmpx when the session ends. Traditionally, PAM did not exist and utmpx logout updates (utmp/wtmp back then) were done by init. > If 'login' should not be a user tool and we cannot fix this case then > perhaps it should move to /usr/libexec/login so it is not in the default > path where the user will be enticed to use it. As I said earlier in the thread, I don't think login(1) can be modified to make this case work. Removing its setuid bit would be a start but moving to libexec is the logical conclusion. I have seen terminal emulators run 'login -f $USER' on some systems but likely not FreeBSD. This ensures utmpx is updated but also adds quite a bit of baggage and reduces flexibility (cannot select a custom shell and update utmpx). In FreeBSD, the setuid root /usr/libexec/ulog-helper ensures utmpx can be updated flexibly. -- Jilles Tjoelker