Bug 815375
Summary: | Libacl support of NFSv4 style ACLs | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Ondrej Valousek <ondrejv> |
Component: | acl | Assignee: | Kamil Dudka <kdudka> |
Status: | CLOSED DUPLICATE | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
Severity: | low | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.2 | CC: | 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
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. 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. Reading/writing NFSv4 ACLs is already supported via the nfs4-acl-tools package. *** This bug has been marked as a duplicate of bug 231231 *** (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). (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(-) (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. (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? (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) ... |