On Thursday 22 June 2006 17:15, you wrote:
> 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...
Do you think about something similar to my proposed algorithm for this issue
or have a different idea?
>
> Another concern would be: what UID owns files created by such processes?
To my mind, the euid of the "anonymous" process. That is why I intended to
introduce five and not only two privileges. PRIV_FILE_IDENTITY_OWNER would be
required to create files.
In the scenario with only two privileges, having set
PRIV_FILE_IDENTITY_{WRITE|READ} would give you back your "writing/reading
identity", see my proposed open algorithm for reference.
>
> > >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
