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

["RVP via gnats" <gnats-admin%NetBSD.org@localhost>]

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

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

 On Sun, 27 Oct 2024, David H. Gutteridge via gnats wrote:
 
 > 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).
 >
 
 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:
 
 https://github.com/NetBSD/src/blob/trunk/lib/libutil/login_cap.c#L624
 
 This creates the /private/tmp/NNNN dirs for each user logging into the
 system.
 
 > 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."
 >
 
 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.  This is easily seen; to wit:
 
 $ 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
 $
 
 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.
 
 -RVP
 
 -RVP