"J. Bruce Fields" <[email protected]> wrote on 09/02/2009 11:42:43 AM:
> On Wed, Sep 02, 2009 at 05:54:20PM +0530, Aneesh Kumar K.V wrote:
> > This patch series implement POSIX ACL support for NFSV4 clients
> > using sideband protocol.
>
> What motivates this? Who exactly wants this and why? What would be
> the advantages compared to other options, such as:
The most obvious reason to me is that security information
can be lost as the ACL which was generated by Linux utilities and
client acl tools (which get/set posix acls) are converted by the Linux nfs
v4 client
to NFSv4 ACLs on the wire and then the server converts them back to posix
to save them in ext3 (or ext4 or xfs etc.). This double conversion can
result
in a different ACL returned on subsequent queries (e.g. getfacl) than the
one that the user just set. At worst this is a security exposure and at
best it is confusing to the user (and we don't control the tools).
And Linux client to Linux server is worse than Linux client to some other
servers because of the extra conversion (which is counter intuitive)
> - native v4 support in filesystems, or
Doesn't help now. In the future would be nice to have something
similar to native cifs/ntfs/nfsv4 ACLs in btrfs - but that wouldn't help
for years - and won't help all of the other Linux
file systems. CIFS and NTFS (and SMB2 in the future) could be
modified to return something like an NFSv4 ACL, but local file systems
aren't likely to change. In the meantime we don't even have
a generalized system interface to set/get nfsv4/cifs/ntfs acls so
Linux ACL tools and libraries and server software
like Samba could be updated to handle something other than
posix ACLs. I expect that jra and others of us on the Samba team
would love to see a few Linux file systems support CIFS/NFSv4/NTFS
ACLs but as he has reminded people - posix acls are Linux's native
ACL model.
> - improved client-side acl tools that provided a user interface
> for v4 acls closer to that for v3 acls, or
Problem is that ACLs are a "system feature" and the OS tools,
utilities and desktop GUI tools for Linux use POSIX ACLs since
Linux's "native acl interface" is the posix one. It would make
sense to add a way to query the "preferred acl interface"
for a file system (and NFSv4 client could query the server
perhaps via a named attribute to determine the ACL type
preferred by the server fs). It is important to use the
native ACL model of the server operating system
so that information is not lost unnecessarily in the conversion.
> - a v4.x extension to add support to the main protocol?
Sounds fine to me to add an extension to the main protocol
but I doubt that it would be necessary - no extension was
formally added when v3 was extended for posix acls.
By analogy with cifs - we defined a new request and a new capability
bit for posix acl support. CIFS ACL support is expected
("should" implement) but posix acl support is optional. The
Linux client uses posix acls if the server claims support for it
and it has not been disabled on the client by mount option.
> > The ACL support can be disabled/enabled
> > using -o noacl/-o acl mount option. The feature enables to
> > view and modify POSIX acls from NFSv4 client.
--
Thanks,
Steve
> 2) If POSIX->NFSv4 client mapping is done (as had been suggested IIRC
> by others in the past) at least you lose less data (NFSv4 ACLs are "richer"
> in function than POSIX ACLs - so at least with the POSIX->NFSv4->POSIX
> case you are limiting the user to the subset of choices which are actually
> going to be able to be stored, no inheritence etc.)
>
>
I must say that I do not understand the motivation either. POSIX is not
even a standard and should be replaced with NFSv4 acls.
Even now ext3/ext4 support NFSv4 acls (ok. patch is needed but the patch
is there already).
If the decision was up to me, I would forbid any nfsv4 acls if the
server can not store them properly (i.e. without any conversion) +
forbid using nfsv4 with posix acls over sideband protocol (no standard,
so netapp will never support this and the same is to be expected from
Windows and Solaris). This is just adding mess and confusion.
My 5 cents...
Ondrej
_______________________________________________
NFSv4 mailing list
[email protected]
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
On Thursday, 3 September 2009 16:09:28 Trond Myklebust wrote:
> The main problem has been finding developers with an interest, and with
> enough time on their hands. Andreas Gruenbacher started working on NFSv4
> acls, but due to his time constraints, his work ended up getting farmed
> out to a developer in SGI, and consequently ended up in a black hole
> somewhere...
Indeed ... I transferred as much knowledge as I could to a group of SGI
engineers who were then working on the project for a while. Unfortunately
then the whole group was laid off (for unrelated reasons). I could not find a
sponsor for continuing from there since.
The open issues in the project include some research (e.g., figuring out how
Windows applications behave in practice when using Linux NFSv4 ACLs -- this
is necessary to make a few implementation decisions which the overall design
has left open), and some more implementation / testing / documentation work.
Thanks,
Andreas
I've always thought of NFS as a means for making physical file systems
available across a network. NFS having its own ACLs doesn't fit this
model. E.g., "NFS ACLs" will never be integrated into NTFS. However, I
could imagine NFS ACLs solving the general problem if they were to form
a superset of the ACLs of exportable physical file systems, and the
mechanism for interpreting ACLs for a particular physical file system
could be encoded (or modularized) in such a way that NFS' evaluation of
ACL operations has the same results as the physical file system's
execution of the same ACL operations. You could have a POSIX ACL
module, NTFS ACL module, etc. There's a challenge for 4.2.
ACLs could possibly be made completely opaque to NFS with a module-based
approach.
-Dan
> -----Original Message-----
> From: Ondrej Valousek [mailto:[email protected]]
> Sent: Wednesday, September 02, 2009 11:20 PM
> To: Steve French
> Cc: [email protected]; [email protected];
> [email protected]; Myklebust, Trond; [email protected]; [email protected]
> Subject: Re: POSIX ACL support for NFSV4 (using sideband protocol)
>
>
> > 2) If POSIX->NFSv4 client mapping is done (as had been
> suggested IIRC
> > by others in the past) at least you lose less data (NFSv4
> ACLs are "richer"
> > in function than POSIX ACLs - so at least with the
> POSIX->NFSv4->POSIX
> > case you are limiting the user to the subset of choices which are
> > actually going to be able to be stored, no inheritence etc.)
> >
> >
>
> I must say that I do not understand the motivation either.
> POSIX is not even a standard and should be replaced with NFSv4 acls.
> Even now ext3/ext4 support NFSv4 acls (ok. patch is needed
> but the patch is there already).
>
> If the decision was up to me, I would forbid any nfsv4 acls
> if the server can not store them properly (i.e. without any
> conversion) + forbid using nfsv4 with posix acls over
> sideband protocol (no standard, so netapp will never support
> this and the same is to be expected from Windows and
> Solaris). This is just adding mess and confusion.
>
> My 5 cents...
> Ondrej
> _______________________________________________
> NFSv4 mailing list
> [email protected]
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
>
On Wed, Sep 2, 2009 at 3:22 PM, J. Bruce Fields<[email protected]> wrote=
:
> On Wed, Sep 02, 2009 at 01:56:23PM -0500, Steve French wrote:
>> "J. Bruce Fields" <[email protected]> wrote on 09/02/2009 11:42:43 AM=
:
>> > On Wed, Sep 02, 2009 at 05:54:20PM +0530, Aneesh Kumar K.V wrote:
>> > > This patch series implement POSIX ACL support for NFSV4 clients
>> > > using sideband protocol.
>> >
>> > What motivates this? =A0Who exactly wants this and why? =A0 What would=
be
>> > the advantages compared to other options, such as:
>>
>> The most obvious reason to me is that security information
>> can be lost as the ACL which was generated by Linux utilities and
>> client acl tools (which get/set posix acls) are converted by the Linux n=
fs
>> v4 client
>
> The kernel v4 client doesn't do that--it passes untouched v4 acls to and
> from userspace.
1) Passing untouched ACLs doesn't help as these ACLs would be NFS specific,
and unrecognized by the default Linux tools and GUIs. Access Control on
file and directory objects is a "system feature" - part of the OS (it has b=
een
that way since at least OS/2, not just Windows, MacOS, Solaris etc..)
You wouldn't require the user to use different tools for modifying ACLs in
Windows, MacOS and require that the user try to figure out the ACL model of
the underlying file system before deciding what tool to use and what permis=
sions
to apply to his home directory
2) If POSIX->NFSv4 client mapping is done (as had been suggested IIRC
by others in the past) at least you lose less data (NFSv4 ACLs are "richer"
in function than POSIX ACLs - so at least with the POSIX->NFSv4->POSIX
case you are limiting the user to the subset of choices which are actually
going to be able to be stored, no inheritence etc.)
--=20
Thanks,
Steve
_______________________________________________
NFSv4 mailing list
[email protected]
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
On Thu, Sep 3, 2009 at 1:20 AM, Ondrej Valousek<[email protected]> wrote:
>
>> 2) If POSIX->NFSv4 client mapping is done (as had been suggested IIRC
>> by others in the past) at least you lose less data (NFSv4 ACLs are
>> "richer"
>> in function than POSIX ACLs - so at least with the POSIX->NFSv4->POSIX
>> case you are limiting the user to the subset of choices which are actually
>> going to be able to be stored, no inheritence etc.)
>>
> I must say that I do not understand the motivation either. POSIX is not even
> a standard and should be replaced with NFSv4 acls.
> Even now ext3/ext4 support NFSv4 acls (ok. patch is needed but the patch is
> there already).
If someone were able to convince the linux-fsdevel community to change
fs/posix_acls.c
(or add an fs/cifs_acls.c) to handle NFSv4/CIFS/NTFS ACL evaluation, and add
support to store these richer ACLs on disk for the future (e.g. for
btrfs), that would be
great - but with no local file system in kernel which can store NFSv4 ACLs and
no code to evaluate these ACLs in the VFS and with a NACK from fsdevel when
others tried this a few years ago (even after MacOS and others moved to the
CIFS/NTFS ACLs model)
> If the decision was up to me, I would forbid any nfsv4 acls if the server
> can not store them properly (i.e. without any conversion)
That would be a pretty dramatic loss of function - being forced to use
the primitive
mode bits to protect files if the server were Linux - and could be
worseeven NetApp does
some ACL mapping
--
Thanks,
Steve
On Thu, 2009-09-03 at 00:46 -0700, Muntz, Daniel wrote:
>
> ACLs could possibly be made completely opaque to NFS with a module-based
> approach.
>
> -Dan
Something to be aware of here is that once you turn a field opaque you
introduce a bunch of other issues. The MAC attribute that I've been
proposing in the IETF is mostly opaque and it has caused some problems
with interoperability. Some questions to be answered are
1) what is the initial set of modules defined? They aren't going to let
you take an opaque field and run away with it to do as you please. I've
been working on ways to define an initial set of label formats to make
the working group happier.
2) How are you going to specify these modules? It needs to be in a way
that implementors can easily use it. Are these specifications maintained
through the IETF or are they maintained by an outside organization?
3) How do modules translate between themselves. Are you going to only
allow like ACL modules to communicate? Will you have a mechanism for
those with ACL type A to still use a system with ACL type B? Will a
server be able to support both ACL type A and B? What happens if you
want both a Windows NFSv4 client and a Linux NFSv4 client to use the
same shares?
These are just some ideas to think about when you decide to make this
opaque.
Dave
_______________________________________________
NFSv4 mailing list
[email protected]
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
On Thu, Sep 3, 2009 at 2:46 AM, Muntz, Daniel<[email protected]> wrote:
> I've always thought of NFS as a means for making physical file systems
> available across a network. ?NFS having its own ACLs doesn't fit this
> model. ?E.g., "NFS ACLs" will never be integrated into NTFS. ?However, I
> could imagine NFS ACLs solving the general problem if they were to form
> a superset of the ACLs of exportable physical file systems
NFSv4 ACLs are similar to CIFS/NTFS ACLS. NFSv4 ACLs were
originally based on CIFS/NTFS ACLs so it would be reasonable
to export them from NTFS (although the SIDs (UUIDs) have to be mapped
to local Linux UIDs - we have user space code that can do this in Samba).
Note Samba server can map between the CIFS/NTFS and NFSv4
ACLs already and has for many years.
JRA on the Samba team and Andreas have done some good
presentations on the differences in ACL models, but other than
storing the "mask" or equivalent - POSIX ACLs can be thought of as
a subset of NFSv4/CIFS/NTFS ACLs
--
Thanks,
Steve
On Wed, Sep 02, 2009 at 01:56:23PM -0500, Steve French wrote:
> "J. Bruce Fields" <[email protected]> wrote on 09/02/2009 11:42:43 AM:
> > On Wed, Sep 02, 2009 at 05:54:20PM +0530, Aneesh Kumar K.V wrote:
> > > This patch series implement POSIX ACL support for NFSV4 clients
> > > using sideband protocol.
> >
> > What motivates this? Who exactly wants this and why? What would be
> > the advantages compared to other options, such as:
>
> The most obvious reason to me is that security information
> can be lost as the ACL which was generated by Linux utilities and
> client acl tools (which get/set posix acls) are converted by the Linux nfs
> v4 client
The kernel v4 client doesn't do that--it passes untouched v4 acls to and
from userspace.
(We do have some patches which do that conversion in libacl, but I don't
believe any distribution has ever applied them.)
> to NFSv4 ACLs on the wire and then the server converts them back to posix
> to save them in ext3 (or ext4 or xfs etc.). This double conversion can
> result
> in a different ACL returned on subsequent queries (e.g. getfacl) than the
> one that the user just set.
Do you have an example? I may be forgetting some corner case, but I
don't believe there should be any, *except* for those due to name<->id
conversion.
Which is a much larger problem.
(There may also, of course, be translation problems even when only one
side is translating--but I think the id/name translation is still the
bigger problem.)
> At worst this is a security exposure and at
> best it is confusing to the user (and we don't control the tools).
> And Linux client to Linux server is worse than Linux client to some other
> servers because of the extra conversion (which is counter intuitive)
>
> > - native v4 support in filesystems, or
> Doesn't help now. In the future would be nice to have something
> similar to native cifs/ntfs/nfsv4 ACLs in btrfs - but that wouldn't help
> for years - and won't help all of the other Linux
> file systems.
Here's one attempt for ext3:
http://www.suse.de/~agruen/nfs4acl/
> CIFS and NTFS (and SMB2 in the future) could be modified to return
> something like an NFSv4 ACL, but local file systems aren't likely to
> change.
Could be. I'd expect serious resistance, but nobody has really tried
yet that I'm aware of.
> In the meantime we don't even have
> a generalized system interface to set/get nfsv4/cifs/ntfs acls so
The current client is using raw xdr-formatted v4 acls in an extended
attribute. We could consider some other interface if that would be more
useful to other projects. (Andreas' patches have a different
xattr-based interface which might serve as another example.)
> Linux ACL tools and libraries and server software
> like Samba could be updated to handle something other than
> posix ACLs. I expect that jra and others of us on the Samba team
> would love to see a few Linux file systems support CIFS/NFSv4/NTFS
> ACLs but as he has reminded people - posix acls are Linux's native
> ACL model.
>
> > - improved client-side acl tools that provided a user interface
> > for v4 acls closer to that for v3 acls, or
> Problem is that ACLs are a "system feature" and the OS tools,
> utilities and desktop GUI tools for Linux use POSIX ACLs since
> Linux's "native acl interface" is the posix one. It would make
> sense to add a way to query the "preferred acl interface"
> for a file system (and NFSv4 client could query the server
> perhaps via a named attribute to determine the ACL type
> preferred by the server fs). It is important to use the
> native ACL model of the server operating system
> so that information is not lost unnecessarily in the conversion.
>
> > - a v4.x extension to add support to the main protocol?
>
> Sounds fine to me to add an extension to the main protocol
> but I doubt that it would be necessary - no extension was
> formally added when v3 was extended for posix acls.
> By analogy with cifs - we defined a new request and a new capability
> bit for posix acl support. CIFS ACL support is expected
> ("should" implement) but posix acl support is optional. The
> Linux client uses posix acls if the server claims support for it
> and it has not been disabled on the client by mount option.
I'm sympathetic to this kind of argument, but it should be made at
[email protected]. It will be much harder to push patches that aren't
based on something well on its way to standardization.
--b.
On Thu, Sep 03, 2009 at 12:46:09AM -0700, Muntz, Daniel wrote:
> I've always thought of NFS as a means for making physical file systems
> available across a network. NFS having its own ACLs doesn't fit this
> model. E.g., "NFS ACLs" will never be integrated into NTFS. However, I
> could imagine NFS ACLs solving the general problem if they were to form
> a superset of the ACLs of exportable physical file systems, and the
> mechanism for interpreting ACLs for a particular physical file system
> could be encoded (or modularized) in such a way that NFS' evaluation of
> ACL operations has the same results as the physical file system's
> execution of the same ACL operations. You could have a POSIX ACL
> module, NTFS ACL module, etc. There's a challenge for 4.2.
>
> ACLs could possibly be made completely opaque to NFS with a module-based
> approach.
>
What would be the acl model on the client side ? Considering that POSIX ACL
is looked at as the native acl model in Linux, I guess we should have the ability
to modify the ACLs using POSIX ACL tools on the nfs client
-aneesh
_______________________________________________
NFSv4 mailing list
[email protected]
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
On Thu, Sep 3, 2009 at 8:55 AM, J. Bruce Fields<[email protected]> wrote:
> On Thu, Sep 03, 2009 at 08:54:06AM -0500, Steve French wrote:
>> if someone were able to convince the linux-fsdevel community to change
>> fs/posix_acls.c
>> (or add an fs/cifs_acls.c) to handle NFSv4/CIFS/NTFS ACL evaluation, and add
>> support to store these richer ACLs on disk for the future (e.g. for
>> btrfs), that would be
>> great - but with no local file system in kernel which can store NFSv4 ACLs and
>> no code to evaluate these ACLs in the VFS and with a NACK from fsdevel when
>
> I don't remember that--do you have a pointer?
Aneesh mentioned one strongly worded objection (I remember more resistance
from others too)
http://kerneltrap.org/mailarchive/linux-fsdevel/2006/6/24/313526
--
Thanks,
Steve
T24gVGh1LCBTZXAgMDMsIDIwMDkgYXQgMDg6MzY6NDRBTSAtMDUwMCwgU3RldmUgRnJlbmNoIHdy
b3RlOgo+IE9uIFRodSwgU2VwIDMsIDIwMDkgYXQgMjo0NiBBTSwgTXVudHosIERhbmllbDxEYW4u
TXVudHpAbmV0YXBwLmNvbT4gd3JvdGU6Cj4gPiBJJ3ZlIGFsd2F5cyB0aG91Z2h0IG9mIE5GUyBh
cyBhIG1lYW5zIGZvciBtYWtpbmcgcGh5c2ljYWwgZmlsZSBzeXN0ZW1zCj4gPiBhdmFpbGFibGUg
YWNyb3NzIGEgbmV0d29yay4gwqBORlMgaGF2aW5nIGl0cyBvd24gQUNMcyBkb2Vzbid0IGZpdCB0
aGlzCj4gPiBtb2RlbC4gwqBFLmcuLCAiTkZTIEFDTHMiIHdpbGwgbmV2ZXIgYmUgaW50ZWdyYXRl
ZCBpbnRvIE5URlMuIMKgSG93ZXZlciwgSQo+ID4gY291bGQgaW1hZ2luZSBORlMgQUNMcyBzb2x2
aW5nIHRoZSBnZW5lcmFsIHByb2JsZW0gaWYgdGhleSB3ZXJlIHRvIGZvcm0KPiA+IGEgc3VwZXJz
ZXQgb2YgdGhlIEFDTHMgb2YgZXhwb3J0YWJsZSBwaHlzaWNhbCBmaWxlIHN5c3RlbXMKPiAKPiBO
RlN2NCBBQ0xzIGFyZSBzaW1pbGFyIHRvIENJRlMvTlRGUyBBQ0xTLiBORlN2NCBBQ0xzIHdlcmUK
PiBvcmlnaW5hbGx5IGJhc2VkIG9uIENJRlMvTlRGUyBBQ0xzIHNvIGl0IHdvdWxkIGJlIHJlYXNv
bmFibGUKPiB0byBleHBvcnQgdGhlbSBmcm9tIE5URlMgKGFsdGhvdWdoIHRoZSBTSURzIChVVUlE
cykgaGF2ZSB0byBiZSBtYXBwZWQKPiB0byBsb2NhbCBMaW51eCBVSURzIC0gd2UgaGF2ZSB1c2Vy
IHNwYWNlIGNvZGUgdGhhdCBjYW4gZG8gdGhpcyBpbiBTYW1iYSkuCgpPbiB0aGUgc2VydmVyIHNp
ZGUsIHlvdSdkIGFjdHVhbGx5IGhhdmUgdG8gbWFwIGJldHdlZW4gU0lEcyBhbmQgTkZTdjQKbmFt
ZXMgKHN0cmluZ3Mgb2YgdGhlIGZvcm0gdXNlckBkb21haW4pLgoKLS1iLgoKPiBOb3RlIFNhbWJh
IHNlcnZlciBjYW4gbWFwIGJldHdlZW4gdGhlIENJRlMvTlRGUyBhbmQgTkZTdjQKPiBBQ0xzIGFs
cmVhZHkgYW5kIGhhcyBmb3IgbWFueSB5ZWFycy4KPiAKPiBKUkEgb24gdGhlIFNhbWJhIHRlYW0g
YW5kIEFuZHJlYXMgaGF2ZSBkb25lIHNvbWUgZ29vZAo+IHByZXNlbnRhdGlvbnMgb24gdGhlIGRp
ZmZlcmVuY2VzIGluIEFDTCBtb2RlbHMsIGJ1dCBvdGhlciB0aGFuCj4gc3RvcmluZyB0aGUgIm1h
c2siIG9yIGVxdWl2YWxlbnQgLSBQT1NJWCBBQ0xzIGNhbiBiZSB0aG91Z2h0IG9mIGFzCj4gYSBz
dWJzZXQgb2YgTkZTdjQvQ0lGUy9OVEZTIEFDTHMKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KTkZTdjQgbWFpbGluZyBsaXN0Ck5GU3Y0QGxpbnV4LW5mcy5v
cmcKaHR0cDovL2xpbnV4LW5mcy5vcmcvY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL25mc3Y0
On Thu, Sep 03, 2009 at 08:54:06AM -0500, Steve French wrote:
> On Thu, Sep 3, 2009 at 1:20 AM, Ondrej Valousek<[email protected]> wrote:
> >
> >> 2) If POSIX->NFSv4 client mapping is done (as had been suggested IIRC
> >> by others in the past) at least you lose less data (NFSv4 ACLs are
> >> "richer"
> >> in function than POSIX ACLs - so at least with the POSIX->NFSv4->POSIX
> >> case you are limiting the user to the subset of choices which are actually
> >> going to be able to be stored, no inheritence etc.)
> >>
> > I must say that I do not understand the motivation either. POSIX is not even
> > a standard and should be replaced with NFSv4 acls.
> > Even now ext3/ext4 support NFSv4 acls (ok. patch is needed but the patch is
> > there already).
>
> If someone were able to convince the linux-fsdevel community to change
> fs/posix_acls.c
> (or add an fs/cifs_acls.c) to handle NFSv4/CIFS/NTFS ACL evaluation, and add
> support to store these richer ACLs on disk for the future (e.g. for
> btrfs), that would be
> great - but with no local file system in kernel which can store NFSv4 ACLs and
> no code to evaluate these ACLs in the VFS and with a NACK from fsdevel when
I don't remember that--do you have a pointer?
--b.
> others tried this a few years ago (even after MacOS and others moved to the
> CIFS/NTFS ACLs model)
>
> > If the decision was up to me, I would forbid any nfsv4 acls if the server
> > can not store them properly (i.e. without any conversion)
>
> That would be a pretty dramatic loss of function - being forced to use
> the primitive
> mode bits to protect files if the server were Linux - and could be
> worseeven NetApp does
> some ACL mapping
On Thu, Sep 3, 2009 at 8:54 AM, J. Bruce Fields<[email protected]> wrote:
> On Thu, Sep 03, 2009 at 08:36:44AM -0500, Steve French wrote:
>> On Thu, Sep 3, 2009 at 2:46 AM, Muntz, Daniel<[email protected]> wrot=
e:
>> > I've always thought of NFS as a means for making physical file systems
>> > available across a network. =A0NFS having its own ACLs doesn't fit this
>> > model. =A0E.g., "NFS ACLs" will never be integrated into NTFS. =A0Howe=
ver, I
>> > could imagine NFS ACLs solving the general problem if they were to form
>> > a superset of the ACLs of exportable physical file systems
>>
>> NFSv4 ACLs are similar to CIFS/NTFS ACLS. NFSv4 ACLs were
>> originally based on CIFS/NTFS ACLs so it would be reasonable
>> to export them from NTFS (although the SIDs (UUIDs) have to be mapped
>> to local Linux UIDs - we have user space code that can do this in Samba).
>
> On the server side, you'd actually have to map between SIDs and NFSv4
> names (strings of the form user@domain).
Yes ... We could add mapping directly from user@domain to SID - Samba
has something similar,
but we already have both mapping to/from unix uid.
1) SID (UUID, a number) to/from a local Unix UID (which winbind and
others have today)
and
2) user@domain mapped to/from local Unix UID (which NFS user space
code has today)
If
-- =
Thanks,
Steve
On Thu, 2009-09-03 at 08:54 -0500, Steve French wrote:
> If someone were able to convince the linux-fsdevel community to change
> fs/posix_acls.c
> (or add an fs/cifs_acls.c) to handle NFSv4/CIFS/NTFS ACL evaluation, and add
> support to store these richer ACLs on disk for the future (e.g. for
> btrfs), that would be
> great - but with no local file system in kernel which can store NFSv4 ACLs and
> no code to evaluate these ACLs in the VFS and with a NACK from fsdevel when
> others tried this a few years ago (even after MacOS and others moved to the
> CIFS/NTFS ACLs model)
I don't think the fs-devel community is a problem. We have native
support for plenty of these filesystems which use alternative acl
models, so a very good case can be made for their inclusion.
The main problem has been finding developers with an interest, and with
enough time on their hands. Andreas Gruenbacher started working on NFSv4
acls, but due to his time constraints, his work ended up getting farmed
out to a developer in SGI, and consequently ended up in a black hole
somewhere...
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com
T24gV2VkLCBTZXAgMDIsIDIwMDkgYXQgMDM6NTM6MTdQTSAtMDUwMCwgU3RldmUgRnJlbmNoIHdy
b3RlOgo+IE9uIFdlZCwgU2VwIDIsIDIwMDkgYXQgMzoyMiBQTSwgSi4gQnJ1Y2UgRmllbGRzPGJm
aWVsZHNAZmllbGRzZXMub3JnPiB3cm90ZToKPiA+IE9uIFdlZCwgU2VwIDAyLCAyMDA5IGF0IDAx
OjU2OjIzUE0gLTA1MDAsIFN0ZXZlIEZyZW5jaCB3cm90ZToKPiA+PiAiSi4gQnJ1Y2UgRmllbGRz
IiA8YmZpZWxkc0BmaWVsZHNlcy5vcmc+IHdyb3RlIG9uIDA5LzAyLzIwMDkgMTE6NDI6NDMgQU06
Cj4gPj4gPiBPbiBXZWQsIFNlcCAwMiwgMjAwOSBhdCAwNTo1NDoyMFBNICswNTMwLCBBbmVlc2gg
S3VtYXIgSy5WIHdyb3RlOgo+ID4+ID4gPiBUaGlzIHBhdGNoIHNlcmllcyBpbXBsZW1lbnQgUE9T
SVggQUNMIHN1cHBvcnQgZm9yIE5GU1Y0IGNsaWVudHMKPiA+PiA+ID4gdXNpbmcgc2lkZWJhbmQg
cHJvdG9jb2wuCj4gPj4gPgo+ID4+ID4gV2hhdCBtb3RpdmF0ZXMgdGhpcz8gwqBXaG8gZXhhY3Rs
eSB3YW50cyB0aGlzIGFuZCB3aHk/IMKgIFdoYXQgd291bGQgYmUKPiA+PiA+IHRoZSBhZHZhbnRh
Z2VzIGNvbXBhcmVkIHRvIG90aGVyIG9wdGlvbnMsIHN1Y2ggYXM6Cj4gPj4KPiA+PiBUaGUgbW9z
dCBvYnZpb3VzIHJlYXNvbiB0byBtZSBpcyB0aGF0IHNlY3VyaXR5IGluZm9ybWF0aW9uCj4gPj4g
Y2FuIGJlIGxvc3QgYXMgdGhlIEFDTCB3aGljaCB3YXMgZ2VuZXJhdGVkIGJ5IExpbnV4IHV0aWxp
dGllcyBhbmQKPiA+PiBjbGllbnQgYWNsIHRvb2xzICh3aGljaCBnZXQvc2V0IHBvc2l4IGFjbHMp
IGFyZSBjb252ZXJ0ZWQgYnkgdGhlIExpbnV4IG5mcwo+ID4+IHY0IGNsaWVudAo+ID4KPiA+IFRo
ZSBrZXJuZWwgdjQgY2xpZW50IGRvZXNuJ3QgZG8gdGhhdC0taXQgcGFzc2VzIHVudG91Y2hlZCB2
NCBhY2xzIHRvIGFuZAo+ID4gZnJvbSB1c2Vyc3BhY2UuCj4gCj4gMSkgUGFzc2luZyB1bnRvdWNo
ZWQgQUNMcyBkb2Vzbid0IGhlbHAgYXMgdGhlc2UgQUNMcyB3b3VsZCBiZSBORlMgc3BlY2lmaWMs
Cj4gYW5kIHVucmVjb2duaXplZCBieSB0aGUgZGVmYXVsdCBMaW51eCB0b29scyBhbmQgR1VJcy4g
IEFjY2VzcyBDb250cm9sIG9uCj4gZmlsZSBhbmQgZGlyZWN0b3J5IG9iamVjdHMgaXMgYSAic3lz
dGVtIGZlYXR1cmUiIC0gcGFydCBvZiB0aGUgT1MgKGl0IGhhcyBiZWVuCj4gdGhhdCB3YXkgc2lu
Y2UgYXQgbGVhc3QgT1MvMiwgbm90IGp1c3QgV2luZG93cywgTWFjT1MsIFNvbGFyaXMgZXRjLi4p
Cj4gIFlvdSB3b3VsZG4ndCByZXF1aXJlIHRoZSB1c2VyIHRvIHVzZSBkaWZmZXJlbnQgdG9vbHMg
Zm9yIG1vZGlmeWluZyBBQ0xzIGluCj4gV2luZG93cywgTWFjT1MgYW5kIHJlcXVpcmUgdGhhdCB0
aGUgdXNlciB0cnkgdG8gZmlndXJlIG91dCB0aGUgQUNMIG1vZGVsIG9mCj4gdGhlIHVuZGVybHlp
bmcgZmlsZSBzeXN0ZW0gYmVmb3JlIGRlY2lkaW5nIHdoYXQgdG9vbCB0byB1c2UgYW5kIHdoYXQg
cGVybWlzc2lvbnMKPiB0byBhcHBseSB0byBoaXMgaG9tZSBkaXJlY3RvcnkKPiAyKSBJZiBQT1NJ
WC0+TkZTdjQgY2xpZW50IG1hcHBpbmcgaXMgZG9uZSAoYXMgaGFkIGJlZW4gc3VnZ2VzdGVkIElJ
UkMKPiBieSBvdGhlcnMgaW4gdGhlIHBhc3QpIGF0IGxlYXN0IHlvdSBsb3NlIGxlc3MgZGF0YSAo
TkZTdjQgQUNMcyBhcmUgInJpY2hlciIKPiBpbiBmdW5jdGlvbiB0aGFuIFBPU0lYIEFDTHMgLSBz
byBhdCBsZWFzdCB3aXRoIHRoZSBQT1NJWC0+TkZTdjQtPlBPU0lYCj4gY2FzZSB5b3UgYXJlIGxp
bWl0aW5nIHRoZSB1c2VyIHRvIHRoZSBzdWJzZXQgb2YgY2hvaWNlcyB3aGljaCBhcmUgYWN0dWFs
bHkKPiBnb2luZyB0byBiZSBhYmxlIHRvIGJlIHN0b3JlZCwgbm8gaW5oZXJpdGVuY2UgZXRjLikK
CklmIEkgcmVtZW1iZXIgY29ycmVjdGx5LCBMaW51eCdzIHBvc2l4IGFjbCBzdXBwb3J0IHdhcyBh
ZGRlZCBhdCBhYm91dAp0aGUgc2FtZSB0aW1lIHRoZSBORlN2NC4wIHNwZWMgd2FzIGJlaW5nIHdy
aXR0ZW4tLUkgc2VlbSB0byByZWNhbGwgdGhlCmZpcnN0IEFDTCBwYXRjaGVzIGJlaW5nIG1lcmdl
ZCBhcm91bmQgdGhlIHNhbWUgdGltZSBhcyB0aGUgZmlyc3QgTkZTdjQKcGF0Y2hlcz8gIEF0IHdo
aWNoIHBvaW50IGl0IHdhcyByZWFzb25hYmxlIHRvIHNheSB0aGF0IG5vYm9keSByZWFsbHkKdXNl
ZCAiUE9TSVgiIEFDTHMsIGFuZCBub2JvZHkgY291bGQgZXZlciBldmVuIGFncmVlIG9uIGEgc2lu
Z2xlIHN0YW5kYXJkCmZvciB0aGVtLCBzbyB3aHkgYm90aGVyPwoKU28gYW5vdGhlciB3YXkgdG8g
c3RhdGUgeW91ciBhcmd1bWVudCAjMSB3b3VsZCBiZSB0byBzYXkgdGhhdCBhIGxvdCBoYXMKY2hh
bmdlZCBzaW5jZSB0aGVuOiBMaW51eCBhZG1pbmlzdHJhdG9ycyBoYXZlIGdvdHRlbiB1c2VkIHRv
IEFDTHMsIHYyL3YzCmFuZCBDSUZTIGhhdmUgZ2FpbmVkIHN1cHBvcnQgZm9yIHRoZW0sIGV0Yy4s
IHNvIHRoZXkncmUgZXN0YWJsaXNoZWQgbm93CmFuZCB3ZSBoYXZlIHRvIHN1cHBvcnQgdGhlbS4K
CkkgdGhpbmsgdGhhdCBhcmd1bWVudCB3b3VsZCBuZWVkIHRvIGJlIG1hZGUgdG8gbmZzdjRAaWV0
Zi5vcmcsIGFuZCB3aWxsCm5lZWQgc29tZSBldmlkZW5jZSB0byBiYWNrIGl0IHVwLiAgKFVuZm9y
dHVuYXRlbHksIEkgc2VlIHRoYXQgb24gbXkgdmVyeQpyZWNlbnQgKFVidW50dSA5LjEwIGFscGhh
KSBsaW51eCBkZXNrdG9wLCBhY2wgc3VwcG9ydCBvbiB0aGUgZmlsZXN5c3RlbQppc24ndCB0dXJu
ZWQgb24sIGFuZCBuYXV0aWx1cyBkb2Vzbid0IGFwcGVhciB0byBrbm93IGhvdyB0byBlZGl0IGFj
bHMuCk9uIHRoZSBvdGhlciBoYW5kLCBldmVyeXRoaW5nJ3MgY29tcGlsZWQgYWdhaW5zdCBsaWJh
Y2wsIGFuZCB0aGUKY29tbWFuZGxpbmUgdXRpbGl0aWVzIGFwcGVhciB0byBoYXZlIGJlZW4gaW5z
dGFsbGVkIGJ5IGRlZmF1bHQuKQoKLS1iLgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwpORlN2NCBtYWlsaW5nIGxpc3QKTkZTdjRAbGludXgtbmZzLm9yZwpo
dHRwOi8vbGludXgtbmZzLm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbmZzdjQ=
On Thu, Sep 3, 2009 at 9:16 AM, J. Bruce Fields<[email protected]> wrote:
> If I remember correctly, Linux's posix acl support was added at about
> the same time the NFSv4.0 spec was being written--I seem to recall the
> first ACL patches being merged around the same time as the first NFSv4
> patches?
NFSv4 RFC was December 2000 (CIFS/NTFS ACLs, which were much more
complex than earlier OS/2 ACLs, are about 4 years earlier than NFSv4
ACLs). POSIX ACL support was added to mainline Linux kernel at the
end of 2002 (see below):
2002/10/31 02:34:21-05:00 tytso
Port of (bugfixed) 0.8.50 acl-ext2 to 2.5
This patch adds ACL support to the ext2 filesystem.
2002/10/31 02:33:05-05:00 tytso
Port of (bugfixed) 0.8.50 acl-ext3 to 2.5.
This patch adds ACL support to the ext3 filesystem.
2002/10/31 02:30:17-05:00 tytso
Port 0.8.50 acl-xattr patch to 2.5 (harmonize header file with SGI/XFS)
This patch provides converts extended attributes passed in from user
space to a generic Posix ACL representation.
--
Thanks,
Steve
On Wednesday 02 September 2009 22:22:06 J. Bruce Fields wrote:
> On Wed, Sep 02, 2009 at 01:56:23PM -0500, Steve French wrote:
> > In the meantime we don't even have a generalized system interface to
> > set/get nfsv4/cifs/ntfs acls
>
> The current client is using raw xdr-formatted v4 acls in an extended
> attribute. We could consider some other interface if that would be more
> useful to other projects. (Andreas' patches have a different
> xattr-based interface which might serve as another example.)
Yes, the current nfsv4 client exposes NFSv4 ACLs with "user@domain" and
"group@domain" identifiers in xattrs. Users and groups of local processes and
files are are identified by ID though, so the kernel would have to map between
"user@domain" and "group@domain" identifiers and IDs even for local accesses.
This doesn't make sense. The native NSFv4 ACL prototype [1] uses IDs in its
xattr format instead; all the ID mapping logic remains in NFSv4 (and in Samba
for CIFS).
[1] http://www.suse.de/~agruen/nfs4acl/
Andreas
On Mon, Oct 5, 2009 at 11:31 AM, Andreas Gruenbacher <[email protected]> wrote:
> On Wednesday 02 September 2009 22:22:06 J. Bruce Fields wrote:
>> On Wed, Sep 02, 2009 at 01:56:23PM -0500, Steve French wrote:
>> > In the meantime we don't even have a generalized system interface to
>> > set/get nfsv4/cifs/ntfs acls
>>
>> The current client is using raw xdr-formatted v4 acls in an extended
>> attribute. ?We could consider some other interface if that would be more
>> useful to other projects. ?(Andreas' patches have a different
>> xattr-based interface which might serve as another example.)
>
> Yes, the current nfsv4 client exposes NFSv4 ACLs with "user@domain" and
> "group@domain" identifiers in xattrs. Users and groups of local processes and
> files are are identified by ID though, so the kernel would have to map between
> "user@domain" and "group@domain" identifiers and IDs even for local accesses.
> This doesn't make sense. The native NSFv4 ACL prototype [1] uses IDs in its
> xattr format instead; all the ID mapping logic remains in NFSv4 (and in Samba
> for CIFS).
>
> [1] http://www.suse.de/~agruen/nfs4acl/
Recently I looked through NFSv4.1 spec, and it seems to address some
ACL incompatibilities (with CIFS) by extending the NFSv4 ACL model.
Should we be aiming for an eventual interface that would work for NFSv4.1
or limiting it to current NFSv4?
Any idea on the state of NFSv4.1 it seems to be stuck for almost a year?
--
Thanks,
Steve