Adding linux-api...
On Fri, May 29, 2015 at 11:00 AM, Andreas Grünbacher
[off-list ref] wrote:
2015-05-29 15:15 GMT+02:00 Trond Myklebust [off-list ref]:
quoted
[reply reordered]
So having revisited the reasons why I chose the system.nfs4_acl
interface when we did NFSv4 ACLs, I'm not sure we should implement
system.richacl for the NFS client at all.
Your assertion that "when symbolic user@domain and group@domain names
are used in the acl, user-space needs to perform ID mapping in the
same way as the kernel" is WRONG. User space needs do no such thing,
and that was the whole point of the interface; to allow the user to
specify ACLs in a format that is checked only on the _server_, and not
on the client.
That's only half true. Right now, user-space applications trying to copy
permissions between an nfs mount and another file system will fail unless the
application has explicitly been made nfs aware and supports the
"system.nfs4_acl"
attribute (as well as some other acl mechanism if the permissions go beyond the
file mode).
The same problem exists when trying to make sense of acls.
It seems unreasonable to me to expect applications other than special file
system maintenance tools to cater to such file system differences; there are
just too many file systems out there for that to work. Instead, it
would be better
to use an interface that can be generalized across file systems.
My point is that system.richacl is not such an interface. It can only
ever work for local filesystems that understand and store local uids
and gids. It has no support for the remote users/groups that are
stored on your NFS/SMB server unless they happen to have a local
mapping into uids and gids, and so the API is inappropriate to replace
the existing NFSv4 acl API on the client.
quoted
The problem is that you are 100% reliant on an accurate idmapper in
order to convert the name@domain to a _correct_ uid/gid. It isn't
sufficient to convert to just any valid uid/gid, because if your ACL
tool is trying to edit the ACL, you can end up converting all those
DENY modes for user 'Johnny_Rotten@blackhats.are.us' into DENY modes
for user 'nobody'.
...and yes, libnfsidmap will happily convert all unknown
user/groupnames into whatever uid/gid corresponds to 'nobody' without
returning an error.
That's indeed a problem, and I can think of two ways of addressing it:
First, acl editors need to be careful about nobody entries; they need to be
aware that nobody could actually stand for somebody else. (We could map
unmappable users and groups to something else than nobody, but that
might just shift the problem without improve anything.)
What is the editor supposed to do about an entry it cannot even
interpret, let alone store back to the server?
Second, we could add support for passing through unmappable Who values
as is. But that raises the problem of how to pass thtough and represent
different kinds of identifiers: NFSv4 users user@domain and group@domain
strings; smb users SIDs; maybe more.
Now you have a mixture of some stuff that is being translated into
local uid/gid format and therefore needs translating back when you're
going to update the ACL, and some stuff that is not. What is the value
of doing the mapping here?
Trond
2015-05-29 17:24 GMT+02:00 Trond Myklebust [off-list ref]:
quoted
It seems unreasonable to me to expect applications other than special file
system maintenance tools to cater to such file system differences; there are
just too many file systems out there for that to work. Instead, it
would be better
to use an interface that can be generalized across file systems.
My point is that system.richacl is not such an interface. It can only
ever work for local filesystems that understand and store local uids
and gids. It has no support for the remote users/groups that are
stored on your NFS/SMB server unless they happen to have a local
mapping into uids and gids, and so the API is inappropriate to replace
the existing NFSv4 acl API on the client.
That can be changed if we find a reasonable solution.
quoted
quoted
The problem is that you are 100% reliant on an accurate idmapper in
order to convert the name@domain to a _correct_ uid/gid. It isn't
sufficient to convert to just any valid uid/gid, because if your ACL
tool is trying to edit the ACL, you can end up converting all those
DENY modes for user 'Johnny_Rotten@blackhats.are.us' into DENY modes
for user 'nobody'.
...and yes, libnfsidmap will happily convert all unknown
user/groupnames into whatever uid/gid corresponds to 'nobody' without
returning an error.
That's indeed a problem, and I can think of two ways of addressing it:
First, acl editors need to be careful about nobody entries; they need to be
aware that nobody could actually stand for somebody else. (We could map
unmappable users and groups to something else than nobody, but that
might just shift the problem without improve anything.)
What is the editor supposed to do about an entry it cannot even
interpret, let alone store back to the server?
In the end, it will have to be a user decision what to do about such entries,
the editor can warn the user and make it harder to make mistakes though.
quoted
Second, we could add support for passing through unmappable Who values
as is. But that raises the problem of how to pass thtough and represent
different kinds of identifiers: NFSv4 users user@domain and group@domain
strings; smb users SIDs; maybe more.
Now you have a mixture of some stuff that is being translated into
local uid/gid format and therefore needs translating back when you're
going to update the ACL, and some stuff that is not. What is the value
of doing the mapping here?
If you don't translate, you cannot copy the permissions to another file
system. In the ideal case, everything can be translated; where that fails,
the user probably wants to know.
Thanks,
Andreas
On Fri, May 29, 2015 at 11:00 AM, Andreas Grünbacher
[off-list ref] wrote:
quoted
2015-05-29 15:15 GMT+02:00 Trond Myklebust
[off-list ref]:
quoted
quoted
[reply reordered]
So having revisited the reasons why I chose the system.nfs4_acl
interface when we did NFSv4 ACLs, I'm not sure we should implement
system.richacl for the NFS client at all.
Your assertion that "when symbolic user@domain and group@domain
names
quoted
quoted
are used in the acl, user-space needs to perform ID mapping in the
same way as the kernel" is WRONG. User space needs do no such thing,
and that was the whole point of the interface; to allow the user to
specify ACLs in a format that is checked only on the _server_, and
not on the client.
That's only half true. Right now, user-space applications trying to
copy permissions between an nfs mount and another file system will
fail unless the application has explicitly been made nfs aware and
supports the "system.nfs4_acl"
attribute (as well as some other acl mechanism if the permissions go
beyond the file mode).
The same problem exists when trying to make sense of acls.
It seems unreasonable to me to expect applications other than special
file system maintenance tools to cater to such file system
differences; there are just too many file systems out there for that
to work. Instead, it would be better to use an interface that can be
generalized across file systems.
My point is that system.richacl is not such an interface. It can only ever work
for local filesystems that understand and store local uids and gids. It has no
support for the remote users/groups that are stored on your NFS/SMB
server unless they happen to have a local mapping into uids and gids, and so
the API is inappropriate to replace the existing NFSv4 acl API on the client.
Could we have both xattrs? Or a mount option that specifies which xattr to have?
That way folks who don't have local idmapping for every remote identity can use system.nfs4_acl while those who have local mapping for all remote identies and need to use a wide variety of tools can use system.richacl? system.richacl would obviously need to be documented that this issue can arise. But that will forever be an issue, unless we store the ACL with symbolic names, copying from a remote server to a local filesystem will always be lossy if the idmapping is incomplete.
Maybe that's too messy...
Frank
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 29, 2015 at 11:45 AM, Andreas Grünbacher
[off-list ref] wrote:
2015-05-29 17:24 GMT+02:00 Trond Myklebust [off-list ref]:
quoted
quoted
It seems unreasonable to me to expect applications other than special file
system maintenance tools to cater to such file system differences; there are
just too many file systems out there for that to work. Instead, it
would be better
to use an interface that can be generalized across file systems.
My point is that system.richacl is not such an interface. It can only
ever work for local filesystems that understand and store local uids
and gids. It has no support for the remote users/groups that are
stored on your NFS/SMB server unless they happen to have a local
mapping into uids and gids, and so the API is inappropriate to replace
the existing NFSv4 acl API on the client.
That can be changed if we find a reasonable solution.
quoted
quoted
quoted
The problem is that you are 100% reliant on an accurate idmapper in
order to convert the name@domain to a _correct_ uid/gid. It isn't
sufficient to convert to just any valid uid/gid, because if your ACL
tool is trying to edit the ACL, you can end up converting all those
DENY modes for user 'Johnny_Rotten@blackhats.are.us' into DENY modes
for user 'nobody'.
...and yes, libnfsidmap will happily convert all unknown
user/groupnames into whatever uid/gid corresponds to 'nobody' without
returning an error.
That's indeed a problem, and I can think of two ways of addressing it:
First, acl editors need to be careful about nobody entries; they need to be
aware that nobody could actually stand for somebody else. (We could map
unmappable users and groups to something else than nobody, but that
might just shift the problem without improve anything.)
What is the editor supposed to do about an entry it cannot even
interpret, let alone store back to the server?
In the end, it will have to be a user decision what to do about such entries,
the editor can warn the user and make it harder to make mistakes though.
quoted
quoted
Second, we could add support for passing through unmappable Who values
as is. But that raises the problem of how to pass thtough and represent
different kinds of identifiers: NFSv4 users user@domain and group@domain
strings; smb users SIDs; maybe more.
Now you have a mixture of some stuff that is being translated into
local uid/gid format and therefore needs translating back when you're
going to update the ACL, and some stuff that is not. What is the value
of doing the mapping here?
If you don't translate, you cannot copy the permissions to another file
system. In the ideal case, everything can be translated; where that fails,
the user probably wants to know.
Why are we more worried about a hypothetical copy of the file to
another filesystem than we are about representing the ACL correctly
for the filesystem that the file is actually on? Your ACL on the
remote SMB server windows.publicserver.com may not be fully
represented when you copy the file to your local filesystem; get over
it... However if you are authorised to edit the ACL on
windows.publicserver.com, and you can't set it to something that can
be enforced correctly by windows.publicserver.com, then you have a
real problem.
Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html