Re: kern/58438 (Compatibility issues with per-user-temp [described security(7) man page])

["David H. Gutteridge via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/58438; it has been noted by GNATS.

From: "David H. Gutteridge" <david%gutteridge.ca@localhost>
To: RVP <rvp%SDF.ORG@localhost>, gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/58438 (Compatibility issues with per-user-temp [described
 security(7) man page])
Date: Sun, 27 Oct 2024 17:53:59 -0400

 On Sun, 2024-10-27 at 11:38 +0000, RVP wrote:
 > On Sun, 27 Oct 2024, David H. Gutteridge via gnats wrote:
 >=20
 > > I've never used this feature, but from looking at what's documented
 > > in
 > > security(7) and what /etc/rc.d/perusertmp does, I can't see how it
 > > would work at all as-is. According to the steps you've listed, you'd
 > > end up with a /tmp link that points to /private/tmp/@ruid. But
 > > nothing
 > > has populated the actual per-user directories at this point. If
 > > you're
 > > root, it would expect /private/tmp/0 as a directory, for example.
 > > Each
 > > UID-specific directory would need (secured) permissions appropriate
 > > to
 > > that account, of course. I see nothing in the rc.d infrastructure
 > > that
 > > would create this (nor is it mentioned in the man page).
 > >=20
 >=20
 > There's a very obscure trick which makes per-user-tmp dirs work. See
 > the code in setusercontext() which every login-type program (eg. sshd)
 > ends up calling:
 >=20
 > https://github.com/NetBSD/src/blob/trunk/lib/libutil/login_cap.c#L624
 >=20
 > This creates the /private/tmp/NNNN dirs for each user logging into the
 > system.
 >=20
 
 Well, I guess that teaches me not to rely on code inspection instead of
 turning the feature on to check! Heh. I looked into login(1) itself, but
 not there.
 
 I wonder what nonaka@ intended to address with that GitHub gist patch,
 then. It was created five years after the code you reference was added.
 Perhaps in attempted response to this very type of issue.
 
 > > You wrote "Other programs like ed(1) or vi(1) do not have a problem
 > > to
 > > write to this symlinked temp directory on the other hand."
 > >=20
 >=20
 > Programs like ed(1) and vi(1) work because they don't apply
 > realpath(3)
 > to their temp. filenames. tmux(1), however, uses realpath() on its
 > socket
 > pathname. And, the way realpath() works, testing each component for a
 > symlink, then using readlink(2) on symlinks, is what causes this
 > failure
 > because what readlink() returns contains `@ruid' which is _not_
 > expanded
 > because that's _not_ a symlink. The kernel only expands magic tokens
 > in
 > _symlinks_ and no where else.=C2=A0 This is easily seen; to wit:
 >=20
 > $ realpath /tmp
 > /private/tmp/@ruid		# <--- note: @ruid, not 1000 or
 > whatever
 > $ realpath /private/tmp/@ruid
 > /private/tmp/@ruid		# <--- no expansion as not a symlink
 > $ readlink /tmp
 > /private/tmp/@ruid		# as expected
 > $ readlink -v /private/tmp/@ruid
 > readlink: /private/tmp/@ruid: lstat: No such file or directory
 > $
 >=20
 > I made a hacky patch (duplicating the entire symlink_magic() machinery
 > present in kern/vfs_lookup.c) awhile back for do_sys_readlinkat()
 > which
 > expands these magic tokens, but, that then needed a lot more elsewhere
 > (because of the expansion removing the tokens). I've given up for the
 > time-being.
 
 I guess I find it a bit concerning that this feature was added which (1)
 doesn't work with some basic use cases and (2) doesn't document this
 limitation. #2 is easy enough to remedy.
 
 Thanks,
 
 Dave