On Thu, Jun 22, 2006 at 11:55:05AM +0200, [EMAIL PROTECTED] wrote: > >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.
The "canonical" example would be, I think, ssh-agent(1), although I'm not sure it's safe to drop basic privileges given the possibility of it using complex crypto frameworks (currently it uses OpenSSL, but through it it could use PKCS#11). A user that cannot modify anything, not even temp files made by them, seems much too narrowly constrained. > As I understand the proposal, you can still read/modify world > accessible files. Yes. > >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. It could be made to work... Another concern would be: what UID owns files created by such processes? > >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. For non-basic privs we can always do things with the client's root credential and, when creating files, use the create_as option in NFSv4. Then the client could emulate FILE_DAC_*. For basic privs it's harder; if the client had a "nobody" credential then it could use that. The general solution to the NFS problem with privileges is, IMO, as I outlined earlier, through the GSS-API. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
