You are right that vi or mktemp will not longer function with this approach. On the other hand, only programs that will really know what they are doing will drop basic privileges. I do not see a reason for most applications (like vi) will do so. Imagine a process has no identity (it dropped the required privileges). Of course, it should not be able to create file it is itself not able to open. In my opinion, this would be inconsistent.
My mentor made the suggestion that I should provide the list with a prototype implementation of the new privileges for a filesystem and also write a demo program that shows that it works. Later on, I may modify ssh-agent to demonstrate the new privileges on a program that really benefit from it. To the list: What file system should I use to implement my prototype? Do you prefer 5(+2) or 2(+2) privileges (the +2 is for the case that even reading writing globally writable/readable files should be denied). What checking order should I use? (I am in favour of possibility 2). Is the open policy consistent for you or should the creation of files should be generally forbidden if not all new privileges are set? Thanks in advance Johannes Nicolai On Thursday 22 June 2006 12:56, you wrote: > >Concerning the reopen problem of files created in world writable dire= > >ctories: > >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 creatio= > >n is denied. > > `Uhm, this requires the anonymous user to have all its files world > read//write which is a non-starter if you ask me. > > >With following this algorithm, every file we were able to open, we ar= > >e also able to reopen. > > Yes, but that requires changing code so programs like "vi" and library > routines like mktemp() no longer function. > > Casper _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
