From owner-freebsd-hackers@freebsd.org Tue Mar 21 22:57:45 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 3C0ECD17EE5 for ; Tue, 21 Mar 2017 22:57:45 +0000 (UTC) (envelope-from chris@sinjakli.co.uk) Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) (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 D3CA210F4 for ; Tue, 21 Mar 2017 22:57:44 +0000 (UTC) (envelope-from chris@sinjakli.co.uk) Received: by mail-wr0-x243.google.com with SMTP id y90so713862wrb.1 for ; Tue, 21 Mar 2017 15:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sinjakli-co-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=oLyVSepcjM9eLvq2+DjNDGrtclkkxRg7QA5nam/yVu4=; b=hb2lJUdtIVs4wwmxSkRCNSymt95CclbUgkKpTmHUCMA5wH9ZnZ7g764VILjR00z07a DmKBB90p7Cv96mwnyVGZBf9cBb5/i0aqsMSoldRK7Xw4RnRaBg71SCeaoTJA3BvShIkd 053M0DdQQ543bv5AvruksAsvU8IPeOIqb7P/9Xy3OqbBVkPmk7dFCQ049axtd7YAW+JI VnpbkO3C1k/DOOzQPhnBgBjESIh4sc6s/p6r7hFj0sRuY/30x7slELfEhgPCxfGPT6QG hR+m8i0LB2edyGdU4sz0CrnCg3kCkcV/UGwzYNjqPyB527olTLjDIP9E0hZ8GXXF5tEn GKUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=oLyVSepcjM9eLvq2+DjNDGrtclkkxRg7QA5nam/yVu4=; b=evB1NQQ++RVD9oovMthbQhOqc5+p+gcUMqeMjoT9Fa4hfdgcCtSv3nXVJSTSzM177y bOiZ1K2lZCokztW+Rxo6NuaLmWAJcCliCUUUfQIx7hpJzOY1cY6OLFs78W1a1TCAYYFJ +c73zz0LMm96+svPMt7zEBX3RMrbcBfXx41KRsP6yRHdoteWf56Ylm8Z9xUvKEYBChdS eXJmrzpNQlpLDIO2Uo6/V41zyPKYSjleB4rPQ0UMPhvuiGT2JJqPnTwnmOWvrOidSiQs K9qxfkenT4HSVoV+fR0IXfqtAPvZKNL1uACIrOxrhbufHdB0Nq+hFLoVf5bUFwVADAcl DI6w== X-Gm-Message-State: AFeK/H1wserB0P4b2iMzi7rEbWvBDH6PS9oAfP9AjahoNBiWff+lsaQ0K9WphVx9s6dbryWhk17lbKKJLSB0TQ== X-Received: by 10.223.155.17 with SMTP id b17mr31523878wrc.181.1490137062805; Tue, 21 Mar 2017 15:57:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.176.4 with HTTP; Tue, 21 Mar 2017 15:57:22 -0700 (PDT) From: Chris Sinjakli Date: Tue, 21 Mar 2017 22:57:22 +0000 Message-ID: Subject: A historical curiosity in su(1) To: 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 22:57:45 -0000 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