Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1355936 > unrolled thread

Re: [PATCH v18 00/22] Richacls (Core and Ext4)

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v18 00/22] Richacls (Core and Ext4) Christoph Hellwig <hch@infradead.org> - 2016-03-11 15:10 +0100
    Re: [PATCH v18 00/22] Richacls (Core and Ext4) Andreas Gruenbacher <agruenba@redhat.com> - 2016-03-11 17:20 +0100
      Re: [PATCH v18 00/22] Richacls (Core and Ext4) Steve French <smfrench@gmail.com> - 2016-03-11 21:10 +0100
        Re: [PATCH v18 00/22] Richacls (Core and Ext4) Jeremy Allison <jra@samba.org> - 2016-03-12 00:10 +0100
          Re: [PATCH v18 00/22] Richacls (Core and Ext4) Andreas Gruenbacher <agruenba@redhat.com> - 2016-03-14 00:10 +0100
            Re: [PATCH v18 00/22] Richacls (Core and Ext4) Jeremy Allison <jra@samba.org> - 2016-03-14 05:00 +0100
        Re: [PATCH v18 00/22] Richacls (Core and Ext4) Christoph Hellwig <hch@infradead.org> - 2016-03-15 08:20 +0100
          Re: [PATCH v18 00/22] Richacls (Core and Ext4) Steve French <smfrench@gmail.com> - 2016-03-16 04:50 +0100
      Re: [PATCH v18 00/22] Richacls (Core and Ext4) Christoph Hellwig <hch@infradead.org> - 2016-03-15 08:20 +0100
        Re: [PATCH v18 00/22] Richacls (Core and Ext4) Jeremy Allison <jra@samba.org> - 2016-03-15 16:50 +0100
          Re: [PATCH v18 00/22] Richacls (Core and Ext4) Volker Lendecke <Volker.Lendecke@SerNet.DE> - 2016-03-15 21:40 +0100
            Re: [PATCH v18 00/22] Richacls (Core and Ext4) Steve French <smfrench@gmail.com> - 2016-03-16 04:30 +0100

#1355936 — Re: [PATCH v18 00/22] Richacls (Core and Ext4)

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.

[toc] | [next] | [standalone]

#1356028

On Fri, Mar 11, 2016 at 3:01 PM, Christoph Hellwig <hch@infradead.org> 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

[toc] | [prev] | [next] | [standalone]

#1356165

On Fri, Mar 11, 2016 at 10:11 AM, Andreas Gruenbacher
<agruenba@redhat.com> wrote:
> On Fri, Mar 11, 2016 at 3:01 PM, Christoph Hellwig <hch@infradead.org> 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

[toc] | [prev] | [next] | [standalone]

#1356280

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...

[toc] | [prev] | [next] | [standalone]

#1356768

On Sat, Mar 12, 2016 at 12:02 AM, Jeremy Allison <jra@samba.org> 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

[toc] | [prev] | [next] | [standalone]

#1356880

On Mon, Mar 14, 2016 at 12:02:13AM +0100, Andreas Gruenbacher wrote:
> On Sat, Mar 12, 2016 at 12:02 AM, Jeremy Allison <jra@samba.org> 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 :-).

[toc] | [prev] | [next] | [standalone]

#1357845

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.

[toc] | [prev] | [next] | [standalone]

#1358514

On Tue, Mar 15, 2016 at 2:14 AM, Christoph Hellwig <hch@infradead.org> 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

[toc] | [prev] | [next] | [standalone]

#1357846

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.

[toc] | [prev] | [next] | [standalone]

#1358113

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 :-).

[toc] | [prev] | [next] | [standalone]

#1358231

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

[toc] | [prev] | [next] | [standalone]

#1358486

On Tue, Mar 15, 2016 at 3:17 PM, Volker Lendecke
<Volker.Lendecke@sernet.de> 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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web