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: Gnats Bugs <gnats-bugs%netbsd.org@localhost>
Cc: 
Subject: Re: kern/58438 (Compatibility issues with per-user-temp [described
 security(7) man page])
Date: Sat, 26 Oct 2024 20:41:33 -0400

 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).
 
 So you'd need to also create each directory that @ruid would
 contextually point to under /private/tmp before it will work. Since
 you're using tmpfs, you'd have to redo this each time after boot (or
 otherwise initiating the feature). You'd need to figure out which UIDs
 are relevant for you, presumably at least two. (I'm not sure there'd be
 any point applying a sticky bit to these directories, given they're
 supposed to be isolated per-user anyway.)
 
 (Well, if you were using a non-volatile tmp, by default, you'd still
 have to recreate each user's directory every time, as from what I see
 /etc/rc.d/cleartmp also doesn't take this concept into account and
 would remove all the per-UID directories each time, too. In that case
 you could disable it via rc.conf(5), of course. If you just tweaked
 perusertmp to create the extra directories, cleartmp would immediately
 remove them out from under you, too, since it runs afterwards.)
 
 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." Are you
 certain that those actually tried to use /tmp in the first place, and
 successfully wrote there? vi(1) uses /var/tmp, not /tmp, for its
 recovery files. (Yes, it can use /tmp for other purposes.) Based on
 what you shared, I can't follow how vi(1) would have written to "/tmp"
 successfully either.
 
 It seems there are functional and probably documentation issues with
 this feature. (I suppose if it really "just worked" the man page
 wouldn't need to spell out that there are dedicated per-user
 directories, but there'd still need to be a facility provided to
 specify which ones to create, so that would be documented as well.)
 
 Regards,
 
 Dave