linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Drew Leske <drew.leske@computecanada.ca>
Cc: linux-nfs@vger.kernel.org
Subject: Re: Non-root chown, NFSv4 ACLs
Date: Tue, 19 Dec 2017 12:18:33 -0500	[thread overview]
Message-ID: <20171219171833.GF19967@fieldses.org> (raw)
In-Reply-To: <A140722D-FE81-4E44-9ED0-1279E857B636@computecanada.ca>

On Wed, Dec 13, 2017 at 12:28:01PM -0800, Drew Leske wrote:
> >> The remaining question for me then is around the NFSv4 ACL and the
> >> ownership change permission, and whether I should be able to get that
> >> to work, especially on a stock system.
> > 
> > No.  When you set an ACL, the server just translates that ACL to the
> > closet POSIX ACL it can find.  And the filesystem code just enforces
> > that POSIX ACL.  POSIX ACLs have no equivalent to WRITE_OWNER.  I can't
> > remember what the code in fs/nfsd/nfs4acl.c does--the only choices would
> > be to either ignore the bit or fail, I think it does the former.
> 
> It does the former.  The POSIX ACL is stored in a short and the bit for NFS4_ACE_WRITE_OWNER is 0x80000, so it just drops off.
> 
> > (In theory knfsd could store the full v4 ACL in an extended attribute
> > and do its own enforcement on the side--I think Samba can do something
> > like this.  This seems complicated to me and I'd rather add richacl
> > support to the filesystems, but that effort has stalled.)
> 
> It seems complicated and would split the POSIX ACL code from the NFSv4 ACL code, with little benefit for most people, with more risk due to the extra code to be maintained.  Given that all the translation code is already in place, I would be more inclined to leave it as is and maybe store, in addition and optionally, the untranslated NFSv4 ACL separately, so enforcement, which currently works, is left alone in the implementation and representation, which is lacking due to the retranslation back from POSIX ACL to NFSv4 ACL, can be switched on at the server if desired and passed back to the clients.  But I digress...
> 
> I've been looking at this over the last couple of days with the idea of storing the WRITE_OWNER permission as additional  extended attribute on the exported filesystem, initially as an array of UIDs/GIDs.  I think this should be workable: POSIX ACLs are stored as extended attributes and so this would be in addition to that.
> 
> Does this seem like a reasonable approach?
> 
> Would there be much interest in this, if implemented?

I don't know.  I think it would be awkward to map from NFSv4 or SMB ACLs
to that, so I don't know that it would get adoption by Samba or knfsd.

There may be some simpler solution for your own use case.

--b.

      reply	other threads:[~2017-12-19 17:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-07 19:43 Non-root chown, NFSv4 ACLs Drew Leske
2017-12-07 20:05 ` Frank Filz
2017-12-07 20:21   ` Drew Leske
2017-12-07 21:34 ` J. Bruce Fields
2017-12-07 22:54   ` Drew Leske
2017-12-07 23:15     ` J. Bruce Fields
2017-12-09  0:53       ` Drew Leske
2017-12-13 20:28       ` Drew Leske
2017-12-19 17:18         ` J. Bruce Fields [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171219171833.GF19967@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=drew.leske@computecanada.ca \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).