Jason Thorpe wrote:

> Specifically, I think it would be good to formalize this in API somehow,
> perhaps even engaging with other open source OS projects to standardize
> on a "private temp area" API.  For example, perhaps mkstemp(3) and
> friends could be changed to understand some simple format strings, such
> as %T (that would expand to ${TMPDIR} if set, or some reasonable default
> like _PATH_TMP if not set).

yes, that would be great - but as you note below, this doesn't eliminate
the need for some magic for assurance. :)

> That said, having the magic would be good for legacy programs...

> So, first of all, I don't like littering the top-level directory with
> extra stuff.  So, let's pick a generic place to put the "real" temp
> dirs... like maybe /private/tmp (hey, there's prior art for this, at
> least :-)

okay - that sounds good. read further though:

> It would be nice of setusercontext(3) could take care of making sure the
> private temp directory exists, rather than making login(1) do it. 
> setusercontext(3) could also set TMPDIR in the environment -- this would
> make any well-behaved program DTRT out of the box.

christos suggested we can make the code in login(1) a bit smarter: it
would readlink("/tmp") and if it's a symlink, it would take the
componenet of the link target up to "@uid" (say, "/private/tmp", in the
case of "/private/tmp/@uid") and create the private temp dir there.

I think it makes sense, because it also allows us to lose the login.conf
variable. in this scheme, this can work:

	# echo "per_user_tmp=YES" >> /etc/rc.conf
	# /etc/rc.d/perusertmp start

I see your point about setusercontext(3). I'm assuming it's for cases
where login(1) is simply not used (ssh)? probably it is a more logical
bottle neck for the code in question indeed.

-e.