From: steve <steve@steve-ss.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Jeff Layton <jlayton@poochiereds.net>, linux-nfs@vger.kernel.org
Subject: Re: POSIX acls over nfs4
Date: Thu, 23 Feb 2012 17:08:07 +0100 [thread overview]
Message-ID: <4F466467.3030506@steve-ss.com> (raw)
In-Reply-To: <20120223154215.GA26706@fieldses.org>
On 02/23/2012 04:42 PM, J. Bruce Fields wrote:
> On Thu, Feb 23, 2012 at 04:33:14PM +0100, steve wrote:
>> On 02/23/2012 03:40 PM, J. Bruce Fields wrote:
>>> On Thu, Feb 23, 2012 at 12:53:28PM +0100, steve wrote:
>>>> Hi Jeff
>>>> Thanks for the reply. I'm trying to make the files created in a
>>>> share take on group rw.
>>>>
>>>> The trouble is that I've already tried setting the acl's via
>>>> nfs4_setfacl on the mounted share too (please see details below).
>>>> The acl + appears on the unmounted share and behaves as expected
>>>> even when it is not mounted. The mounted share however ignores the
>>>> acl I've set. I've tried remounting but still no acl is effective.
>>>> My workaround is to scan the folder and change the files to group rw
>>>> every few seconds.
>>> Without looking at your details, apologies:
>>>
>>> First, if you want an ace on a directory to be inherited by files and
>>> directories created under that directory, make sure you're setting the f
>>> and d flags (see nfs4_getfacl -H).
>>>
>>> Second, there's a umask problem: posix acl inheritance overrides the
>>> umask, but nfs4 acl inheritance isn't doing that. (The client combines
>>> the create mode and the umask and sets both together, there's no way for
>>> the server to even tell what the umask is.)
>>>
>>> (We should do something about this if we can: maybe modifying the client
>>> to scan the directory acl for any inheritable aces and leaving out the
>>> umask if they're found? It has the obvious race, but I seem to recall
>>> we live with that in the v3 case. Or maybe there's something more
>>> clever, but this comes up every now and then and I can't remember a
>>> better solution.)
>>>
>>> --b.
>> Hi again
>> I have this:
>> nfs4_getfacl /mnt/CACTUS/dropbox/
>>
>> A::OWNER@:rwaDxtTcCy
>> A::GROUP@:rwaDxtcy
>> A::EVERYONE@:tcy
>> A:fdi:OWNER@:rwaDxtTcCy
>> A:fdi:GROUP@:rwaDtcy
>> A:fdi:EVERYONE@:tcy
>>
>> but files are created:
>> steve6@hh3:/mnt/CACTUS/dropbox> touch h3
>> ls -la
>> total 8
>> drwxrws--- 2 root suseusers 4096 Feb 19 11:21 .
>> drwxr-xr-x 9 root root 4096 Feb 19 11:11 ..
>> -rw-rw---- 1 steve6 suseusers 0 Feb 19 11:13 h
>> -rw-r----- 1 steve6 suseusers 0 Feb 19 11:21 h3
>>
>> where h is a file created on the unmounted share and h3 on the nfs4
>> mounted share. IOW the file created does not have group rw.
>> Ahhgghh!!
> Right, so see the second point above: what's your umask? (output of the
> "umask" command.)
>
> --b.
>
>> Can anyone see anything wrong?
>>
>> Thanks so much for your patience.
>> Steve.
>>
OK. I see what you mean. umask 0022
So I can have a group rw with posix but not with nfs4_setfacl:-(
That's on openSUSE who default to 0022. The default on Ubuntu is 0002 so
presumably we could have group rw over nfs4 there out of the box?
Is it a lot of work to implement umask override for nfs4? Or make it an
option perhaps?
At the moment I'm using a big hammer and scanning the share every 4
seconds to change the permissions of any files created there. My other
thought was to have the share on a different partition, umask it to 0002
and export that. But these are workarounds. It would be really good to
have the nfs4 acls do it.
Thanks again,
Steve
next prev parent reply other threads:[~2012-02-23 16:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-18 20:08 POSIX acls over nfs4 steve
2012-02-19 17:15 ` steve
2012-02-23 7:15 ` steve
2012-02-23 8:33 ` tao.peng
2012-02-23 12:50 ` steve
2012-02-23 11:39 ` Jeff Layton
2012-02-23 11:53 ` steve
2012-02-23 14:40 ` J. Bruce Fields
2012-02-23 15:33 ` steve
2012-02-23 15:42 ` J. Bruce Fields
2012-02-23 16:08 ` steve [this message]
2012-02-25 8:19 ` steve
2012-02-28 20:05 ` J. Bruce Fields
2012-02-28 23:22 ` steve
2012-02-29 12:44 ` J. Bruce Fields
2012-02-29 14:04 ` steve
2012-02-29 14:09 ` J. Bruce Fields
2012-02-29 14:26 ` steve
2012-02-29 14:32 ` J. Bruce Fields
2012-02-29 14:40 ` steve
2012-03-01 20:56 ` J. Bruce Fields
2012-03-01 22:11 ` steve
2012-03-02 18:03 ` J. Bruce Fields
2012-02-28 20:00 ` J. Bruce Fields
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=4F466467.3030506@steve-ss.com \
--to=steve@steve-ss.com \
--cc=bfields@fieldses.org \
--cc=jlayton@poochiereds.net \
--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).