>Processes like ssh-agent that do not need their "identiity" may drop = >them. An exploit too these processes may not exploit the fact, that t= >he euid/groups of the process allow some file operations that are den= >ied to everyone. Only files that are globally readable/writable/execu= >table may still be accessed (if there is no rule that denies the acce= >ss for the identity of the process). Many daemons never ever need to = >read/write files that are only accessible due to the fact that they r= >un under a special euid/egid/belong to special groups or only need th= >ese rights in the starting phase and drop them later. >Dropping the privileges may also be used to enforce some kind of mand= >atory access control: An administrator that does not want some users = >to change permission of files may withdraw PRIV_FILE_IDENTITY_OWNER i= >n their login shell.
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. In that case, the fact of having five different privileges to shadow the five FILE privileges is perhaps going overboard. It's also perhaps more easily understood when referred to in the frame of reference of an anonymous user. There are also some other strange corner cases; e.g., opening files in /tmp with a umask other than 0. Casper _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
