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.
With following this algorithm, every file we were able to open, we are also able to reopen. -----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] im Auftrag von [EMAIL PROTECTED] Gesendet: Do 22.06.2006 11:55 An: Nicolas Williams Cc: Nicolai Johannes; [EMAIL PROTECTED]; zfs-discuss@opensolaris.org; Mark Shellenbaum Betreff: Re: AW: AW: [zfs-discuss] Proposal for new basic privileges related with filesystem access checks >On Thu, Jun 22, 2006 at 01:01:38AM +0200, [EMAIL PROTECTED] wrote: >> I'm not sure if I like the name, then; nor the emphasis on the >> euid/egid (as those terms are not commonly used in the kernel; >> there's a reason why the effective uid was cr->cr_uid and not cr_euid. >> >> In other words, what your are doing is creating a "nobody" user with >> an ordinary user id. > >Yes. It's kind of enticing. I'm not entirely clear as to the problem which it solves; I think I'd much rather have a user which cannot modify anything. As I understand the proposal, you can still read/modify world accessible files. >As I interpret the proposal file creation in /tmp would succeed, but >opening existing files owned by the process' actual euid cannot be >opened if thes basic privs are dropped. Right; but often programs work by reopening such files; that will now fail. >How would dropping this basic priv work with NFS though? Not until we make privileges visible over NFS which is a tough nut to crack. Casper _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
