On Mon, Feb 29, 2016 at 09:17:05AM +0100, Andreas Gruenbacher wrote:
> Al,
>
> could you please make sure you are happy with the current version of the
> richacl patch queue for the next merge window?
I'm still not happy.
For one I still see no reason to merge this broken ACL model at all.
It provides our actualy Linux users no benefit at all, while breaking
a lot of assumptions, especially by adding allow and deny ACE at the
same sime.
It also doesn't help with the issue that the main thing it's trying
to be compatible with (Windows) actually uses a fundamentally different
identifier to apply the ACLs to - as long as you're still limited
to users and groups and not guids we'll still have that mapping problem
anyway.
But besides that fundamental question on the purpose of it I also
don't think the code is suitable, more in the individual patches.
On Fri, Mar 11, 2016 at 06:01:34AM -0800, Christoph Hellwig wrote:
> On Mon, Feb 29, 2016 at 09:17:05AM +0100, Andreas Gruenbacher wrote:
> > Al,
> >
> > could you please make sure you are happy with the current version of the
> > richacl patch queue for the next merge window?
>
> I'm still not happy.
>
> For one I still see no reason to merge this broken ACL model at all.
> It provides our actualy Linux users no benefit at all, while breaking
> a lot of assumptions, especially by adding allow and deny ACE at the
> same sime.
Could you explain what you mean by "adding allow and deny ACE at the
same time"?
> It also doesn't help with the issue that the main thing it's trying
> to be compatible with (Windows) actually uses a fundamentally different
> identifier to apply the ACLs to - as long as you're still limited
> to users and groups and not guids we'll still have that mapping problem
> anyway.
Agreed, but, one step at a time? My impression is that the Samba people
still consider this a step forward for Linux compatibility.
--b.
>
> But besides that fundamental question on the purpose of it I also
> don't think the code is suitable, more in the individual patches.
On Fri, Mar 11, 2016 at 3:01 PM, Christoph Hellwig <[email protected]> wrote:
> On Mon, Feb 29, 2016 at 09:17:05AM +0100, Andreas Gruenbacher wrote:
>> Al,
>>
>> could you please make sure you are happy with the current version of the
>> richacl patch queue for the next merge window?
>
> I'm still not happy.
>
> For one I still see no reason to merge this broken ACL model at all.
> It provides our actualy Linux users no benefit at all,
This permission model is useful in mixed environments that involve
UNIX and Windows machines. Think of NAS boxes with Linux and Windows
clients, for example. It also fits the NFSv4 ACL model very well. If
you're not a user dealing with such environments, then the model
likely won't provide any benefits to *you*, and you're better off with
a less complicated permission model. That doesn't say anything about
other users, though.
> while breaking a lot of assumptions,
The model is designed specifically to be compliant with the POSIX
permission model. What assumptions are you talking about?
> especially by adding allow and deny ACE at the same time.
I remember from past discussions that a permission model like the
POSIX ACL model that doesn't have DENY ACEs would be more to your
liking. This argument is dead from the start though: NFSv4 ACLs
without DENY ACEs cannot represent basic file permissions like 0604
where the owning group has fewer permissions than others, for example
(see the richaclex(7) man page). We would end up with a permission
model that isn't even compatible with the traditional POSIX file
permission model, one which nobody else implements or cares about.
> It also doesn't help with the issue that the main thing it's trying
> to be compatible with (Windows) actually uses a fundamentally different
> identifier to apply the ACLs to - as long as you're still limited
> to users and groups and not guids we'll still have that mapping problem
> anyway.
Samba has been dealing with mapping between SIDs and UIDs/GIDs for a
long time, and it's working acceptably well.
We could store SIDs in ACEs, but that wouldn't make the actual
problems go away: Files on Linux have an owner and an owning group
which are identitifed by UID/GID, whereas a file is owned by a SID
which can be either a user or a group in a SID world. Also, processes
on Linux have an owner and a list of groups which are identified by
UID/GID, so any SIDs stored in filesystems would never match a
process, anyway.
(NFSv4 refers to users and groups as opposed to SIDs, and so it
doesn't have this problem.)
Thanks,
Andreas
On Fri, Mar 11, 2016 at 10:11 AM, Andreas Gruenbacher
<[email protected]> wrote:
> On Fri, Mar 11, 2016 at 3:01 PM, Christoph Hellwig <[email protected]> w
> The model is designed specifically to be compliant with the POSIX
> permission model. What assumptions are you talking about?
>
>> especially by adding allow and deny ACE at the same time.
>
> I remember from past discussions that a permission model like the
> POSIX ACL model that doesn't have DENY ACEs would be more to your
> liking. This argument is dead from the start though: NFSv4 ACLs
> without DENY ACEs cannot represent basic file permissions like 0604
> where the owning group has fewer permissions than others, for example
> (see the richaclex(7) man page). We would end up with a permission
> model that isn't even compatible with the traditional POSIX file
> permission model, one which nobody else implements or cares about.
NFSv4.1 (and later) and Samba's (and cifs.ko and NTFS-3g) ACL model are close
enough that doing a common approach that helps all three seems
very reasonable.
A loosely related question is what can be done for tools around existing
interfaces for ACLs. I recently found out NTFS-3g has this xattr:
static const char nf_ns_xattr_ntfs_acl[] = "system.ntfs_acl";
which allows you to query system.ntfs_acl xattr to get their full ACL
(I hope) from NTFS but it hard to read without tools to parse
the blobs better. I was prototyping adding this to cifs.ko for
the most current (SMB3 and later) protocol dialects at least
to allow backup and debug tools to use this to get the actual
ACL. cifs.ko ACL should match almost exactly to NTFS-3g's but
I wish I could find some tools that use this xattr so I could try
comparing this with cacls.exe output and smbcacls (samba tool)
for display detailed ACL information. Any idea of disk management tools
for dumping/viewing/editing ntfs ACLs on Linux for comparison?
>> It also doesn't help with the issue that the main thing it's trying
>> to be compatible with (Windows) actually uses a fundamentally different
>> identifier to apply the ACLs to - as long as you're still limited
>> to users and groups and not guids we'll still have that mapping problem
>> anyway.
>
> Samba has been dealing with mapping between SIDs and UIDs/GIDs for a
> long time, and it's working acceptably well.
>
> We could store SIDs in ACEs, but that wouldn't make the actual
> problems go away: Files on Linux have an owner and an owning group
> which are identitifed by UID/GID, whereas a file is owned by a SID
> which can be either a user or a group in a SID world. Also, processes
> on Linux have an owner and a list of groups which are identified by
> UID/GID, so any SIDs stored in filesystems would never match a
> process, anyway.
Samba's SID<->Username and SID<->UID mapping does work
acceptably well, if a bit "over-configurable" ie with
many choices for how it is done.
(the related RFC2307 mapping needed for mapping usernames
to uids across an enterprise, which Samba's winbind can
also do is helpful much more broadly - since, unlike a uid
which is too small, the username in an NFS ACLs
are basically a one to one mapping for Samba to SIDs (there
are may samba vfs modules for different OS that already
do this, including a one for an earlier version of Linux RichACLs)
Sounds like I need to quickly rework the SMB3 ACL helper functions
for cifs.ko
Also do you know where is the current version of the corresponding
vfs_richacl for
Samba which works with the current RichACL format?
--
Thanks,
Steve
On Fri, Mar 11, 2016 at 02:05:16PM -0600, Steve French wrote:
> Sounds like I need to quickly rework the SMB3 ACL helper functions
> for cifs.ko
>
> Also do you know where is the current version of the corresponding
> vfs_richacl for
> Samba which works with the current RichACL format?
I have a patch for a new vfs_richacl somewhere. I remember
sending it to Andreas for testing...
On Fri, 2016-03-11 at 09:07 -0500, J. Bruce Fields wrote:
> On Fri, Mar 11, 2016 at 06:01:34AM -0800, Christoph Hellwig wrote:
> >
> > On Mon, Feb 29, 2016 at 09:17:05AM +0100, Andreas Gruenbacher
> > wrote:
> > >
> > > Al,
> > >
> > > could you please make sure you are happy with the current version
> > > of the
> > > richacl patch queue for the next merge window?
> > I'm still not happy.
> >
> > For one I still see no reason to merge this broken ACL model at
> > all.
> > It provides our actualy Linux users no benefit at all, while
> > breaking
> > a lot of assumptions, especially by adding allow and deny ACE at
> > the
> > same sime.
> Could you explain what you mean by "adding allow and deny ACE at the
> same time"?
>
> >
> > It also doesn't help with the issue that the main thing it's trying
> > to be compatible with (Windows) actually uses a fundamentally
> > different
> > identifier to apply the ACLs to - as long as you're still limited
> > to users and groups and not guids we'll still have that mapping
> > problem
> > anyway.
> Agreed, but, one step at a time? My impression is that the Samba
> people
> still consider this a step forward for Linux compatibility.
It is a step forward, but being able to store SIDs in the ACL, would be
a much better one.
Simo.
> --b.
>
> >
> >
> > But besides that fundamental question on the purpose of it I also
> > don't think the code is suitable, more in the individual patches.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Mar 12, 2016 at 12:02 AM, Jeremy Allison <[email protected]> wrote:
> On Fri, Mar 11, 2016 at 02:05:16PM -0600, Steve French wrote:
>> Sounds like I need to quickly rework the SMB3 ACL helper functions
>> for cifs.ko
>>
>> Also do you know where is the current version of the corresponding
>> vfs_richacl for
>> Samba which works with the current RichACL format?
>
> I have a patch for a new vfs_richacl somewhere. I remember
> sending it to Andreas for testing...
Ah, the patch was for testing, not resting ... how could I get that mixed up.
I've applied your patch to the latest master branch, made it compile
again, and fixed a few obvious problems. The results I get with
smbcacls look reasonable now.
The code is here:
https://github.com/andreas-gruenbacher/samba richacl
I've used the following smb.conf:
[richacl]
comment = Richacl directory
path = /mnt/ext4
vfs objects = richacl
writeable = yes
browseable = yes
Is there a particular reason why you didn't make vfs_richacl a
dynamically loadable module?
Thanks,
Andreas
On Mon, Mar 14, 2016 at 12:02:13AM +0100, Andreas Gruenbacher wrote:
> On Sat, Mar 12, 2016 at 12:02 AM, Jeremy Allison <[email protected]> wrote:
> > On Fri, Mar 11, 2016 at 02:05:16PM -0600, Steve French wrote:
> >> Sounds like I need to quickly rework the SMB3 ACL helper functions
> >> for cifs.ko
> >>
> >> Also do you know where is the current version of the corresponding
> >> vfs_richacl for
> >> Samba which works with the current RichACL format?
> >
> > I have a patch for a new vfs_richacl somewhere. I remember
> > sending it to Andreas for testing...
>
> Ah, the patch was for testing, not resting ... how could I get that mixed up.
:-).
> I've applied your patch to the latest master branch, made it compile
> again, and fixed a few obvious problems. The results I get with
> smbcacls look reasonable now.
>
> The code is here:
> https://github.com/andreas-gruenbacher/samba richacl
>
> I've used the following smb.conf:
> [richacl]
> comment = Richacl directory
> path = /mnt/ext4
> vfs objects = richacl
> writeable = yes
> browseable = yes
Great ! Once richacls gets into the kernel I'll submit
this into the Samba master branch.
> Is there a particular reason why you didn't make vfs_richacl a
> dynamically loadable module?
Probably sheer lazyness :-).
On Fri, Mar 11, 2016 at 09:07:57AM -0500, J. Bruce Fields wrote:
> Could you explain what you mean by "adding allow and deny ACE at the
> same time"?
NFSv4/rich ACLs have both ALLOW and DENY ACE, which is contrary to
the model how we've operated since the dawn of time.
On Fri, Mar 11, 2016 at 05:11:51PM +0100, Andreas Gruenbacher wrote:
> > while breaking a lot of assumptions,
>
> The model is designed specifically to be compliant with the POSIX
> permission model. What assumptions are you talking about?
People have long learned that we only have 'alloc' permissions. Any
model that mixes allow and deny ACE is a mistake.
> > especially by adding allow and deny ACE at the same time.
>
> I remember from past discussions that a permission model like the
> POSIX ACL model that doesn't have DENY ACEs would be more to your
> liking. This argument is dead from the start though: NFSv4 ACLs
> without DENY ACEs cannot represent basic file permissions like 0604
> where the owning group has fewer permissions than others, for example
> (see the richaclex(7) man page). We would end up with a permission
> model that isn't even compatible with the traditional POSIX file
> permission model, one which nobody else implements or cares about.
So let's stick to the model that we already have.
On Fri, Mar 11, 2016 at 02:05:16PM -0600, Steve French wrote:
> A loosely related question is what can be done for tools around existing
> interfaces for ACLs. I recently found out NTFS-3g has this xattr:
>
> static const char nf_ns_xattr_ntfs_acl[] = "system.ntfs_acl";
>
> which allows you to query system.ntfs_acl xattr to get their full ACL
Bah. Filesystems really have no business exposing random system xattrs,
and we really need to add a filter to fs/xattr.c to not expose
arbitrary attrs ouside the user.* prefix.
On Tue, Mar 15, 2016 at 12:11:03AM -0700, Christoph Hellwig wrote:
> On Fri, Mar 11, 2016 at 05:11:51PM +0100, Andreas Gruenbacher wrote:
> > > while breaking a lot of assumptions,
> >
> > The model is designed specifically to be compliant with the POSIX
> > permission model. What assumptions are you talking about?
>
> People have long learned that we only have 'alloc' permissions. Any
> model that mixes allow and deny ACE is a mistake.
People can also learn and change though :-). One of the
biggest complaints people deploying Samba on Linux have is the
incompatible ACL models.
Whilst I have sympathy with your intense dislike of the
Windows ACL model, this comes down to the core of "who
do we serve ?" IMHO we should serve the users (although
I must confess I'd look awful in a TRON suit :-).
On Tue, Mar 15, 2016 at 08:45:14AM -0700, Jeremy Allison wrote:
> On Tue, Mar 15, 2016 at 12:11:03AM -0700, Christoph Hellwig wrote:
> > People have long learned that we only have 'alloc' permissions. Any
> > model that mixes allow and deny ACE is a mistake.
>
> People can also learn and change though :-). One of the
> biggest complaints people deploying Samba on Linux have is the
> incompatible ACL models.
Just to confirm: I see this a lot in the field. NFSv4 ACLs, while not a
perfect match for NTFS ACLs are a lot closer much more usable to people
who want to serve Windows clients.
Also in the pure linux world there is a lot that you can not express
with just rwx, sgid, sticky bits and friends. If you want the additional
functionality of the richacl bits, I would call it a big mistake to
omit negative aces, if just for the reason not to create yet another
ACLs flavor.
> Whilst I have sympathy with your intense dislike of the
> Windows ACL model, this comes down to the core of "who
> do we serve ?"
The world has enough confusion around ACL semanics, please do not add
more to it by creating your own model of the day.
Volker
On Tue, Mar 15, 2016 at 3:17 PM, Volker Lendecke
<[email protected]> wrote:
> On Tue, Mar 15, 2016 at 08:45:14AM -0700, Jeremy Allison wrote:
>> On Tue, Mar 15, 2016 at 12:11:03AM -0700, Christoph Hellwig wrote:
>> > People have long learned that we only have 'alloc' permissions. Any
>> > model that mixes allow and deny ACE is a mistake.
>>
>> People can also learn and change though :-). One of the
>> biggest complaints people deploying Samba on Linux have is the
>> incompatible ACL models.
>
> Just to confirm: I see this a lot in the field. NFSv4 ACLs, while not a
> perfect match for NTFS ACLs are a lot closer much more usable to people
> who want to serve Windows clients.
Yes (and presumably Macs as well)
--
Thanks,
Steve
On Tue, Mar 15, 2016 at 2:14 AM, Christoph Hellwig <[email protected]> wrote:
> On Fri, Mar 11, 2016 at 02:05:16PM -0600, Steve French wrote:
>> A loosely related question is what can be done for tools around existing
>> interfaces for ACLs. I recently found out NTFS-3g has this xattr:
>>
>> static const char nf_ns_xattr_ntfs_acl[] = "system.ntfs_acl";
>>
>> which allows you to query system.ntfs_acl xattr to get their full ACL
>
> Bah. Filesystems really have no business exposing random system xattrs,
> and we really need to add a filter to fs/xattr.c to not expose
> arbitrary attrs ouside the user.* prefix.
Hopefully we don't consider them random system xattrs, it is
plausible that ntfs uses these for user space tools that I don't
have.
At least for cifs.ko a similar subset (querying ACLs, streams and
reparse info e.g.)
to the ntfs set would be very helpful. For example,
Being able to query the actual ACL over the wire, is important for backup
and for debug, the only question is whether to do it via an xattr (possibly
being able to have some synergy with existing ntfs-3g tools) or an ioctl
(since adding an NTFS specific syscall for a couple fs doesn't make sense).
For the specific example of the odd ntfs.streams.list xattr, I can see why
they have it. I would have mixed feelings about having no way to tell
streams and EAs from each other
since NTFS-3g displaying streams as xattrs and also Extended
Attributes (EAs) as xattrs
(and if they didn't have an additional xattr to list streams)
without a way to tell the difference (at least a system xattr to list
the alternate
data streams is useful). There is useful information in alternate data streams
that backup (and debugging) programs need for some workloads,
for example the origin (where internet explorer downloaded a file from)
and file classification information.
--
Thanks,
Steve
On 2016-03-15 at 21:17 +0100, Volker Lendecke wrote:
> On Tue, Mar 15, 2016 at 08:45:14AM -0700, Jeremy Allison wrote:
> > On Tue, Mar 15, 2016 at 12:11:03AM -0700, Christoph Hellwig wrote:
> > > People have long learned that we only have 'alloc' permissions. Any
> > > model that mixes allow and deny ACE is a mistake.
> >
> > People can also learn and change though :-). One of the
> > biggest complaints people deploying Samba on Linux have is the
> > incompatible ACL models.
>
> Just to confirm: I see this a lot in the field. NFSv4 ACLs, while not a
> perfect match for NTFS ACLs are a lot closer much more usable to people
> who want to serve Windows clients.
>
> Also in the pure linux world there is a lot that you can not express
> with just rwx, sgid, sticky bits and friends. If you want the additional
> functionality of the richacl bits, I would call it a big mistake to
> omit negative aces, if just for the reason not to create yet another
> ACLs flavor.
>
> > Whilst I have sympathy with your intense dislike of the
> > Windows ACL model, this comes down to the core of "who
> > do we serve ?"
>
> The world has enough confusion around ACL semanics, please do not add
> more to it by creating your own model of the day.
Exacty: Like it or not, Windows ACLs are a fact. And the
approximation by the NFSv4 ACLs is getting closer and closer
with each iteration... ;-) So it is not only that Windows world
looking into this.
As Volker and Jeremy have pointed out, the lack of ACL semantics
is one of things the users of Samba complain about most bitterly.
While Samba can work around it when it is acting exclusively on
the files, this is not an option when NFS or other protocols are
to access the data concurrently. In that case we need more
precision down in the file system. So because they make use of
*existing* formats and semantics, I think Andreas' richacls are
just the way to go, as alien as they may seem from the pure linux
filesystem point of view at first.
Cheers - Michael