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:
Think about a process that runs under user bar and group foo that have all
basic privileges set and tries to access
a file test that is owned by anotheruser and group foo.
The path to the file has search permissions for everyone.
The permission bits are as follows: rwx---rwx
The process is not able to open the file in read mode, an anonymous user would
be, dropping PRIV_FILE_IDENTITY_READ won't allow the access as well (see the
three checking possibilities for details), only having set PRIV_FILE_DAC_READ
would allow the process.
That was the only reason I have not used the term "anonymous user" but used the
expression "benefit from additional rights associated through the process'
identity".
If the file test is owned by a group, the process is not member of, access will
be granted in both cases. If the file is owned by user bar and/or group foo and
rwx bits are rwxrwx-w-, read access is only allowed if PRIV_FILE_IDENTITY_READ
or PRIV_FILE_DAC_READ is set, write access is allowed in every case.
If the path to the file has not search permissions for everyone, but search
permissions for the identity of the process, PRIV_FILE_IDENTITY_SEARCH or
PRIV_FILE_DAC_SEARCH has been set. If the identity of the process has only
search permissions for everyone but not for the identity of the process, only
PRIV_FILE_DAC_SEARCH will help to allow the access.
In case of mixed access modes, the checking possibilities will manage that only
privileges are required, that are actually needed.
The identity is to my mind determined through euid/egid and the associated
groups, what term should I use in order not to cause confusion here?
To the file creation problematic: In the proposal was mentioned, that file
creation is only allowed if PRIV_FILE_OWNER is set and the required privileges
for the initial permissions:
--- quote ---
PRIV_FILE_IDENTITY_OWNER:
Allow the process to benefit from its supplemental rights associated with its
identity (euid, egid and associated groups) during file or directory operations
that require ownership of the file (e. g. change permission bits/acls, change
access and modification times, change group or owner, remove or move in a
directory with the sticky bit). To change permission bits/acls of an owned
file/directory, the PRIV_FILE_IDENTITY_* privileges that correspond with the
permitted/denied operation have to be set as well.
Additional rights gained through PRIV_FILE_OWNER and PRIV_FILE_SETID will not
be affected.
Alternatively, one could define that PRIV_FILE_IDENTITY_OWNER only comes into
play if ALL other PRIV_FILE_IDENTITY_* privileges are set. I favour the first
solution, what do you think about it?
--- end of quote ---
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.
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.
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.
Please tell me, which problems with POSIX and NFS semantics still exist with
the new privileges.
If the semantic of the new permissions is not clear yet, I will give further
examples.
Thanks in advance
Johannes
PS: The longer I think about my three checking possibilities the more I favour
option two.
-----Ursprüngliche Nachricht-----
Von: Nicolas Williams [mailto:[EMAIL PROTECTED]
Gesendet: Do 22.06.2006 01:36
An: [EMAIL PROTECTED]
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.
> 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.
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.
How would dropping this basic priv work with NFS though?
Nico
--
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
