On Thu, Jun 22, 2006 at 02:45:50AM +0200, Nicolai Johannes wrote:
> Spo as I have understood you, explaining the new privileges with the
> term "anonymous user" would be better? I actually thought about that
> idea, but there is a subtle difference:
Hmmm, no I have no good name for it.
> Concerning the discussion whether five privileges are too much for the
> purpose: My proposal also asks the question whether one should merge
> the five privileges into two ones (PRIV_FILE_IDENTITY_{READ|WRITE}
> with the semantic of state perserving/non state preserving operations.
> To my mind, this is too coarsely grained in order to programmatically
> restrict the power of a privileged/unprivileged process. Furthermore,
> the shadowing of the existing privileges would be sematically more
> consistent. The administrative effort to create nobody users, set
> s-bits for special programs and track the usage of this user would
> also vanish.
Yeah, I think 5 is probably too many. Wouldn't apps that drop them drop
all of them?
> To the NFS/POSIX issue: I am not an expert in this field, but I
> believe that the following two assumptions are right (correct me if I
> am wrong):
>
> 1. Because the presence of all new basic privileges would change
> anything in the established behaviour (check all three checking
> possibilities if in doubt), programs with basic privileges (almost
> all) will not notice the new privs at all.
Right.
> 2. I do not know exactly if permissions for a NFS file are checked on
> server or client or both (I assume at least at the client). The new
> privileges are only checked at the client, so the server is not
> affected at all. In any case, having set/dropped the new privileges,
> the process will be able to access files, it would normally (i.e.
> without having introduced the new privileges) not be able to.
The server checks permissions.
IIRC Least Privilege already has some problems with NFS, namely that
asserting PRIV_FILE_DAC_* over NFS does not work (unless the euid is 0).
There are things that can be done about that problem strictly within the
NFSv4 protocol, but for not asserting basic file privileges? I don't
yet know what can be done within the protocol...
...though in the past I've proposed a stackable GSS-API mechanism or
Kerberos V authorization-data element to convey client-side privilege
information to the server for evaluation there. But this would be well
beyond the scope of your project -- I mention it only for completeness.
Nico
--
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
