Bug 815375

Summary: Libacl support of NFSv4 style ACLs
Product: Red Hat Enterprise Linux 6 Reporter: Ondrej Valousek <ondrejv>
Component: aclAssignee: Kamil Dudka <kdudka>
Status: CLOSED DUPLICATE QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: low Docs Contact:
Priority: unspecified    
Version: 6.2CC: kdudka, pcfe, rmainz, sct
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-07-27 11:00:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ondrej Valousek 2012-04-23 13:51:12 UTC
Description of problem:
Currently, libacl does not support NFSv4 style ACLs so hence Samba as well as many other ACL tools (like GUI editor eiciel for example) can not support NFSv4 style ACLs.
Can we  expect libacl to have some support of NFSv4 at some stage or will its support go via different channels?
Thanks.

Comment 2 Kamil Dudka 2012-04-27 12:10:11 UTC
Related upstream threads:

http://www.spinics.net/lists/linux-nfs/msg27790.html
http://www.mentby.com/Group/samba-technical/nfsv4-acls.html

Note the eiciel package is not something we support.

Comment 3 RHEL Program Management 2012-09-07 05:33:51 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Comment 5 Kamil Dudka 2015-07-27 11:00:00 UTC
Reading/writing NFSv4 ACLs is already supported via the nfs4-acl-tools package.

*** This bug has been marked as a duplicate of bug 231231 ***

Comment 6 Roland Mainz 2015-07-27 11:27:29 UTC
(In reply to Kamil Dudka from comment #5)
> Reading/writing NFSv4 ACLs is already supported via the nfs4-acl-tools
> package.
> 
> *** This bug has been marked as a duplicate of bug 231231 ***

How can this bug be a duplicate of bug #231231 ? The nfs4-acl-tools package is not *library* support which is requested here (and looking at the opensolaris.org/illumos.org sources it's father *easy* to implement).

Comment 7 Kamil Dudka 2015-07-27 11:48:05 UTC
(In reply to Roland Mainz from comment #6)
> How can this bug be a duplicate of bug #231231?

See the summary of bug #231231.

> The nfs4-acl-tools package is not *library* support

nfs4-acl-tools has a command-line interface (on Fedora also a GUI editor).

> which is requested here (and looking at the
> opensolaris.org/illumos.org sources it's father *easy* to implement).

Which implementation are you talking about?

A patch adding NFSv4 support to libacl was rejected by upstream in 2007:

http://pkgs.fedoraproject.org/cgit/acl.git/commit/?id=79867e85

diffstat does not convince me that the implementation was easy:

$ diffstat acl-2.2.39-nfsv4.patch
 exports                              |   30 ++
 include/builddefs.in                 |    2 
 include/libacl_nfs4.h                |   97 ++++++
 include/nfs4.h                       |  397 +++++++++++++++++++++++++++
 libacl/Makefile                      |   28 +
 libacl/__posix_acl_from_nfs4_xattr.c |   60 ++++
 libacl/acl_extended_file.c           |   29 +
 libacl/acl_get_fd.c                  |   50 ++-
 libacl/acl_get_file.c                |   46 ++-
 libacl/acl_n4tp_acl_trans.c          |  439 ++++++++++++++++++++++++++++++
 libacl/acl_nfs4_add_ace.c            |   83 +++++
 libacl/acl_nfs4_add_pair.c           |   60 ++++
 libacl/acl_nfs4_copy_acl.c           |   85 +++++
 libacl/acl_nfs4_free.c               |   61 ++++
 libacl/acl_nfs4_get_who.c            |  103 +++++++
 libacl/acl_nfs4_get_whotype.c        |   60 ++++
 libacl/acl_nfs4_new.c                |   58 +++
 libacl/acl_nfs4_remove_ace.c         |   48 +++
 libacl/acl_nfs4_set_who.c            |   92 ++++++
 libacl/acl_nfs4_xattr_load.c         |  191 +++++++++++++
 libacl/acl_nfs4_xattr_pack.c         |  148 ++++++++++
 libacl/acl_nfs4_xattr_size.c         |   91 ++++++
 libacl/acl_ptn4_acl_trans.c          |  509 +++++++++++++++++++++++++++++++++++
 libacl/acl_ptn4_get_mask.c           |   81 +++++
 libacl/acl_set_fd.c                  |   37 ++
 libacl/acl_set_file.c                |   72 ++++
 libacl/libacl_nfs4.h                 |   97 ++++++
 27 files changed, 3033 insertions(+), 21 deletions(-)

Comment 8 Roland Mainz 2015-07-27 12:35:24 UTC
(In reply to Kamil Dudka from comment #7)
> (In reply to Roland Mainz from comment #6)
> > How can this bug be a duplicate of bug #231231?
> 
> See the summary of bug #231231.
> 
> > The nfs4-acl-tools package is not *library* support
> 
> nfs4-acl-tools has a command-line interface (on Fedora also a GUI editor).
> 
> > which is requested here (and looking at the
> > opensolaris.org/illumos.org sources it's father *easy* to implement).
> 
> Which implementation are you talking about?

The unified "POSIX *draft* ACL" (POSIX/SUS never ratified that API; it was supposed to be replaced by the NFSv4 ACL system but when Sun Microsystems went down noone else pushed that work through the SingleUnixSpecification standard machinery) and "NFSv4/ZFS ACL" API available in every UNIX implementation (Solaris etc.) which has NFSv4 support - except Linux.

This is also an issue with ACL support in archivers (tar(1), pax(1) etc.) where the file format for ACL support is clearly defined and should go through the matching libc APIs.

> A patch adding NFSv4 support to libacl was rejected by upstream in 2007:

1. That was in 2007 - things may have changed since then.
2. If we can't do [1] then we might want to fork() libacl and do what the other UNIX vendors did (well, they licensed Sun's code (which is now available as opensource via illumos.org (Illumos is basically the successor of OpenSolaris)) - we don't have to license it and just use the existing APIs as blueprints (the biggest pain for me would be to find a replacement for SystemV's libavl API since the Solaris algorithm is a bit implicitly tied to AVL trees))

> http://pkgs.fedoraproject.org/cgit/acl.git/commit/?id=79867e85
> 
> diffstat does not convince me that the implementation was easy:
> 
> $ diffstat acl-2.2.39-nfsv4.patch
>  exports                              |   30 ++
>  include/builddefs.in                 |    2 
>  include/libacl_nfs4.h                |   97 ++++++
>  include/nfs4.h                       |  397 +++++++++++++++++++++++++++
>  libacl/Makefile                      |   28 +
>  libacl/__posix_acl_from_nfs4_xattr.c |   60 ++++
>  libacl/acl_extended_file.c           |   29 +
>  libacl/acl_get_fd.c                  |   50 ++-
>  libacl/acl_get_file.c                |   46 ++-
>  libacl/acl_n4tp_acl_trans.c          |  439 ++++++++++++++++++++++++++++++
>  libacl/acl_nfs4_add_ace.c            |   83 +++++
>  libacl/acl_nfs4_add_pair.c           |   60 ++++
>  libacl/acl_nfs4_copy_acl.c           |   85 +++++
>  libacl/acl_nfs4_free.c               |   61 ++++
>  libacl/acl_nfs4_get_who.c            |  103 +++++++
>  libacl/acl_nfs4_get_whotype.c        |   60 ++++
>  libacl/acl_nfs4_new.c                |   58 +++
>  libacl/acl_nfs4_remove_ace.c         |   48 +++
>  libacl/acl_nfs4_set_who.c            |   92 ++++++
>  libacl/acl_nfs4_xattr_load.c         |  191 +++++++++++++
>  libacl/acl_nfs4_xattr_pack.c         |  148 ++++++++++
>  libacl/acl_nfs4_xattr_size.c         |   91 ++++++
>  libacl/acl_ptn4_acl_trans.c          |  509
> +++++++++++++++++++++++++++++++++++
>  libacl/acl_ptn4_get_mask.c           |   81 +++++
>  libacl/acl_set_fd.c                  |   37 ++
>  libacl/acl_set_file.c                |   72 ++++
>  libacl/libacl_nfs4.h                 |   97 ++++++
>  27 files changed, 3033 insertions(+), 21 deletions(-)

Yes, because that code is an overkill in some places.

Comment 9 Kamil Dudka 2015-07-27 14:00:49 UTC
(In reply to Roland Mainz from comment #8)
> The unified "POSIX *draft* ACL" (POSIX/SUS never ratified that API; it was
> supposed to be replaced by the NFSv4 ACL system but when Sun Microsystems
> went down noone else pushed that work through the SingleUnixSpecification
> standard machinery) and "NFSv4/ZFS ACL" API available in every UNIX
> implementation (Solaris etc.) which has NFSv4 support - except Linux.

Which means there is no implementation of the API on top of Linux kernel, right?

> This is also an issue with ACL support in archivers (tar(1), pax(1) etc.)
> where the file format for ACL support is clearly defined and should go
> through the matching libc APIs.

What is "the file format for ACL support"?  Where is it defined?

> > A patch adding NFSv4 support to libacl was rejected by upstream in 2007:
> 
> 1. That was in 2007 - things may have changed since then.

The problem is that we have no mature enough patch for upstream proposal.  Are you volunteering to prepare one and get it upstream?

Comment 10 Roland Mainz 2015-07-27 14:56:47 UTC
(In reply to Kamil Dudka from comment #9)
> (In reply to Roland Mainz from comment #8)
> > The unified "POSIX *draft* ACL" (POSIX/SUS never ratified that API; it was
> > supposed to be replaced by the NFSv4 ACL system but when Sun Microsystems
> > went down noone else pushed that work through the SingleUnixSpecification
> > standard machinery) and "NFSv4/ZFS ACL" API available in every UNIX
> > implementation (Solaris etc.) which has NFSv4 support - except Linux.
> 
> Which means there is no implementation of the API on top of Linux kernel,
> right?

Well, right now the only implementation is in the NFSv4 ACL utils - it should be in the libsec or libc library (see https://docs.oracle.com/cd/E23823_01/html/816-5172/acl-fromtext-3sec.html#scrolltoc for example).

> > This is also an issue with ACL support in archivers (tar(1), pax(1) etc.)
> > where the file format for ACL support is clearly defined and should go
> > through the matching libc APIs.
> 
> What is "the file format for ACL support"?  Where is it defined?

There is no "file format", the ustar and pax archive formats can contain a text blob which is then passed to https://docs.oracle.com/cd/E23823_01/html/816-5172/acl-fromtext-3sec.html#scrolltoc and co which decides how to apply this to a filesystem. There is also a reverse function to return ACLs (POSIX draft or NFSv4 into text blobs again) which then tar/pax can put into the archive.

> > > A patch adding NFSv4 support to libacl was rejected by upstream in 2007:
> > 
> > 1. That was in 2007 - things may have changed since then.
> 
> The problem is that we have no mature enough patch for upstream proposal. 
> Are you volunteering to prepare one and get it upstream?

Please define "volunteering" ... I know what to do but I have my plate pretty much full... dpal would be the right person to ask for a "chunk" of me (or better: my time) ...