In some mail from Theo de Raadt, sie said: > > > Apart from the ability to exchange files between users with > > /tmp, having private /tmp's for each uid using the system (with a non- > > world writeable /tmp) has a lot of merit which I hope someone will someday > > properly explore - i.e. there exist programming languages in which the > > buffer overflow is a non-event, now we need an operating system design > > where the /tmp file race-condition is a non-event. > > Perhaps. But watch what you ask for, because there is software out > there that by itself that swaps uid's while playing (safely) in /tmp. > Any change like this can cause new problems to crop up... 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. Whilst it all sounds nice, I think it'd be somewhat of a hack to actually implement, unless something like union mounts were used for mounting (say) /tmp/root back to /tmp. I'm sure this has been suggested before too. Darren
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:55:14 PDT