[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tue, 26 Mar 2002 10:23:08 +0100
Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.1 (Capitol Reef, i386-debian-linux)
I was wondering: If a user attaches a translator to a node in "/tmp" that
shows, say, "/etc", "/sbin", "/", or something else, and root runs "rm
-Rf /tmp", what will happen?
Will it be:
1. rm sees a directory, recurses, and deletes a lot of important files?
2. rm sees a directory and recurses, but because the translator is
running as, say, oysteivi, the ports provided won't give access to
actually delete stuff oysteivi couldn't delete himself? or
3. rm sees a translator not owned by any id possessed by the current rm
process, tries to remove the translator and go on?
I'm a bit unclear on the port auth stuff, so I'm not sure if 2. is
likely, but if 1. happens, there is a lot of work to do on rm,
tmpwatch/tmpreaper, and mv. (I guess this is they don't allow directory
hardlinks in Unix...)
I guess programs like updatedb/slocate/find need to be able to recognize
translators so that they can avoid spinning forever in an infinitely
deep directory tree created by some users translator.
Can anybody provide any advice on how to best add such translator
support to user space programs? Is putting the important code inside
"#ifdef _HURD_" or somesuch advisable? (do we even have such a #define
to lean on?) Should the code in showtrans and settrans be considered
good examples on how to fix do this? Any other advice for making such
patches easier for upstream maintainers to swallow?
When in doubt: Ask.
- recursive commands,
Oystein Viggen <=