> I think I defeated myself in trying to explain the implementation I was
> trying to describe. For each user, when they login, a virtual /tmp is
> created and that is shared between all sessions that user has. This is
> setup at login time and is carried forth to all children, root or not,
> and cannot be reset (somewhat akin to chroot) unless devious methods are
> employed (i.e. write to /dev/mem).
>
> So if I have 10 logins to host foo, each login sees the same /tmp, even
> the root shells I generate via su/sudo in half. If I login as root, I
> don't have the same /tmp (I get a different one). cron/at jobs would
> be no different. So the `real' /tmp could even be 755 root.wheel.
I see what you are getting at basically /tmp becomes an extention to the
per user memory space. (bad analogy on my part but I can't think of a
better one :)
Although it does rather cripple /tmp in another way: That of sharing
information between users. If I tell another user that the file s/he wants
is in /tmp (as my /home/tim dir is 711 with most files 600) I don't have
to mess with file perms and s/he doesn't have to get the exact right name
to read the file.
You also may have problems as the /tmp space you suggest (~/tmp mapped to
/tmp) is then inside a users quota'ed directory which is often a bad idea,
this blocks logins as no tmp space is avalible hence login fails, so you
can clear out your ~/tmp space, a chicken / egg problem :). You are all
well and good quotaing or mounting /tmp to stop / filling up but the point
is the the /home and /tmp quotas should be different.
--
Tim Fletcher .~.
/V\ L I N U X
tjdf@st-andrews.ac.uk // \ >Don't fear the penguin<
tim@night-shade.demon.co.uk /( )\
^^-^^
"First they ignore you. Then they laugh at you.
Then they fight you. Then you win." - Gandhi
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:55:20 PDT