From owner-freebsd-hackers@freebsd.org Tue Mar 21 23:14:29 2017 Return-Path: Delivered-To: freebsd-hackers@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 DFEDED1678E for ; Tue, 21 Mar 2017 23:14:29 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F4001CE3 for ; Tue, 21 Mar 2017 23:14:29 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-wm0-f51.google.com with SMTP id v203so5250338wmg.0 for ; Tue, 21 Mar 2017 16:14:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=CYKVfsxdm+pMNh7TMZo7NYMWvoZqPlwPIL3aSUIHnpM=; b=Dq2tHhVSbp8XrpO+G06zHq2VqdJXGTp0RSU15yVf8RohGNa9rcTCZRMKh7wDanOzoO wVapZ4M6E9DMoGGi92Ep8ktyPaXevSz812qJzLFynVMloQSD2wwAxYxYz1E1zo8iu+cF FlWw4H0CCnia5ufMsvkeXTczknQY4FuciAuzpxLvFOrqUBES41ObmdJPlmx2DJFfchhG f9laRptPILy5Gyn9MgM3MV7cCAxs4wA40P1G0rW/J2AqQgqciWaVkM+RHfyx5l7AoYh1 gJjM8+SIYtdZA4rw4lr/1J69tcNBfJyM8waB52E+vWOf3SalVWttO1jgTRO8lIzeWvaS cKew== X-Gm-Message-State: AFeK/H3ubjJjxLFDN6L4qAgZznn9r4YmoD8+n4BKpHLSRwgAnO4WwvCw5nKemZM1TsZEdg== X-Received: by 10.28.140.135 with SMTP id o129mr4843262wmd.101.1490138062373; Tue, 21 Mar 2017 16:14:22 -0700 (PDT) Received: from mail-wr0-f179.google.com (mail-wr0-f179.google.com. [209.85.128.179]) by smtp.gmail.com with ESMTPSA id q29sm753950wrc.49.2017.03.21.16.14.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 16:14:22 -0700 (PDT) Received: by mail-wr0-f179.google.com with SMTP id g10so120863987wrg.2 for ; Tue, 21 Mar 2017 16:14:22 -0700 (PDT) X-Received: by 10.223.145.97 with SMTP id j88mr32151087wrj.178.1490138061932; Tue, 21 Mar 2017 16:14:21 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.80.169.4 with HTTP; Tue, 21 Mar 2017 16:14:21 -0700 (PDT) In-Reply-To: References: From: Conrad Meyer Date: Tue, 21 Mar 2017 16:14:21 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: A historical curiosity in su(1) To: Chris Sinjakli Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 23:14:30 -0000 Hi Chris, You might be interested in FreeBSD's copy of the CSRG repository.[0] Some of this logic was changed by karels@ in "r45520"[1] (of course it wasn't Subversion at the time). The previous change[2] message includes "use new getlogin()." Prior to that change, su did not use getlogin/getpwnam. The "BUGS" section of the getlogin(2) manual page says: In earlier versions of the system, getlogin() failed unless the process was associated with a login terminal. The current implementation (using setlogin()) allows getlogin to succeed even when the process has no con- trolling terminal. In earlier versions of the system, the value returned by getlogin() could not be trusted without checking the user ID. Porta- ble programs should probably still make this check. That might explain it? Best, Conrad [0]: https://svnweb.freebsd.org/csrg/usr.bin/su/su.c?view=annotate [1]: https://svnweb.freebsd.org/csrg?view=revision&revision=45520 [2]: https://svnweb.freebsd.org/csrg?view=revision&revision=45127 On Tue, Mar 21, 2017 at 3:57 PM, Chris Sinjakli wrote: > Hi folks, > > I'm doing some digging for a talk I'm working on for PGConf US[1]. > > The talk is one I've given before[2], and last time I gave it I left an open > question right near the end. This time, I'd love to be able to answer it! > > As a heads-up, this is a behaviour I encountered through Ubuntu, but the code > involved is present in a very similar form in FreeBSD, and probably originated > here or in a shared ancestor (the trail goes cold at a 1994 import from BSD > 4.4). > > The open question revolves around the way su(1) determines the user it is being > invoked by. Specifically, it does this using a combination of the result of > getuid and getlogin[3][4]. > > If calling getpwnam on the result of getlogin returns a passwd struct, and the > uid in that struct matches the uid returned by getuid, it returns that passwd > struct. > > If the getpwnam approach fails for either reason, it falls back to using the > result of getpwuid on the result of getuid. > > The thing I'm curious about is why it goes to the trouble of trying to use the > result of getpwnam/getlogin at all. The only time it will return something > different from getpwuid/getuid is if there are two users with the same uid but > different information in the rest of their passwd entry. > > Are there cases where you might want to set up a system this way? I've always > avoided assigning the same uid to multiple users - it seems like a bad idea! > > Jumping back to the point I made in the talk, the result of getlogin can often > be surprising. For example, a daemon restarted by a supervisor (e.g. upstart) > will be associated with the user that issued the restart (i.e. getlogin would > return "chris" if I restarted it, rather than something like "daemon-user"). Any > daemon that calls su will run into this behaviour. > > If, as we do at my current employer, you store your human users in LDAP and your > system users locally, that means a network round-trip every time su is called, > just because a human happened to restart a daemon! > > For what it's worth, this isn't new behaviour. You can find extremely similar > code in FreeBSD's su implementation, and it's been there since at least 1994[5], > with something similar existing in the current code[6]. > > It seems likely to me that all of this behaviour needs to be preserved because > somewhere out there, something will depend on it in a strange way. That said, if > someone knows why it behaves like this, I'd be really interested to know, and to > share the answer as part of my talk! > > Many thanks for reading this, and entertaining a historical itch. > > Chris > > > [1]: http://www.pgconf.us/conferences/2017 > > [2]: https://www.youtube.com/watch?v=Tu-cf-Jki60 > > [3]: > https://github.com/shadow-maint/shadow/blob/db57db52cfd99069c33604eb4a0fee56eb659133/src/su.c#L731 > > [4]: > https://github.com/shadow-maint/shadow/blob/db57db52cfd99069c33604eb4a0fee56eb659133/libmisc/myname.c#L44 > > [5]: > https://github.com/freebsd/freebsd/blob/f9ab90d9d6d02989a075d0f0074496d5b1045e4b/usr.bin/su/su.c#L125 > > [6]: > https://github.com/freebsd/freebsd/blob/d8179bc9ec98d230e00546e4afa2a244e2f123ed/usr.bin/su/su.c#L255 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"