I am afraid, that I dislike the idea as well. You also need to record the privileges of the process (perhaps the process chose to drop and set the new privileges from time to time). It really complicates a safe and easy to verify implementation. To my mind, processes that will drop the new privileges really know what they can do and how they should do things. In my opinion, creating files that may not be accessed by the process if already present should not be allowed at all.
Regards Johannes -----Ursprüngliche Nachricht----- Von: Nicolas Williams [mailto:[EMAIL PROTECTED] Gesendet: Do 22.06.2006 20:11 An: Jonathan Adams Cc: Nicolai Johannes; zfs-discuss@opensolaris.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] Betreff: Re: AW: AW: [zfs-discuss] Proposal for new basic privileges related with filesystem access checks On Thu, Jun 22, 2006 at 11:06:48AM -0700, Jonathan Adams wrote: > On Thu, Jun 22, 2006 at 12:49:03PM -0500, Nicolas Williams wrote: > > On Thu, Jun 22, 2006 at 12:54:32PM +0200, Nicolai Johannes wrote: > > > Concerning the reopen problem of files created in world writable > > > directories: One may use the following algorithm: First compute the > > > permissions of the newly created file. For every permission granted > > > to the user or group, check whether the corresponding > > > identity-privilege is set. If not, the permission also has to be > > > granted for everyone. If this is not the case, file creation is > > > denied. > > > > I was thinking of caching the {vfs, inode #, gen#, pid} and using that > > to allow such processes to re-open files they _recently_ (the cache > > should have LRU/LFU eviction) opened. > > That doesn't seem like a very predictable interface. The security guarantees > are not very strong. Thinking about PID re-use, yes, but I'm not trying to design the specific details -- I think a set of items to cache that provides strong security guarantees can be found. The interface would remain unpredictable in other ways, but that seems like a small price to pay considering the use cases. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
