Re: [PATCH v18 00/22] Richacls (Core and Ext4)
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 signature.asc Description: PGP signature
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
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 signature.asc Description: PGP signature
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
On Tue, Mar 15, 2016 at 2:14 AM, Christoph Hellwigwrote: > 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
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
On Tue, Mar 15, 2016 at 2:14 AM, Christoph Hellwig 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
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
On Tue, Mar 15, 2016 at 3:17 PM, Volker Lendeckewrote: > 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
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
On Tue, Mar 15, 2016 at 3:17 PM, 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. Yes (and presumably Macs as well) -- Thanks, Steve
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
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
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
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
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
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 :-).
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
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 :-).
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
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.
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
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.
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
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.
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
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.
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
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.
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
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.
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
On Mon, Mar 14, 2016 at 12:02:13AM +0100, Andreas Gruenbacher wrote: > On Sat, Mar 12, 2016 at 12:02 AM, Jeremy Allisonwrote: > > 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 :-).
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
On Mon, Mar 14, 2016 at 12:02:13AM +0100, Andreas Gruenbacher wrote: > On Sat, Mar 12, 2016 at 12:02 AM, Jeremy Allison 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 :-).
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
On Sat, Mar 12, 2016 at 12:02 AM, Jeremy Allisonwrote: > 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
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
On Sat, Mar 12, 2016 at 12:02 AM, Jeremy Allison 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
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
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...
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
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...
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
On Fri, Mar 11, 2016 at 10:11 AM, Andreas Gruenbacherwrote: > On Fri, Mar 11, 2016 at 3:01 PM, Christoph Hellwig 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
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
On Fri, Mar 11, 2016 at 10:11 AM, Andreas Gruenbacher wrote: > On Fri, Mar 11, 2016 at 3:01 PM, Christoph Hellwig 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
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
On Fri, Mar 11, 2016 at 3:01 PM, Christoph Hellwigwrote: > 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
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
On Fri, Mar 11, 2016 at 3:01 PM, 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, 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
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
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.
Re: [PATCH v18 00/22] Richacls (Core and Ext4)
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.
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.
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.
[PATCH v18 00/22] Richacls (Core and Ext4)
Al, could you please make sure you are happy with the current version of the richacl patch queue for the next merge window? Changes since the last posting (https://lwn.net/Articles/671398/): * Some combinations of ACL entry flags were not computed correctly when ACL entries were inherited from a directory to files and directories created inside that directory. This is fixed now, with a test case covering all the flag combinations in the richacl package. * Rebases on top of v4.5-rc5. The complete patch queue is available here: git://git.kernel.org/pub/scm/linux/kernel/git/agruen/linux-richacl.git \ richacl-2016-02-22 The richacl user-space utilitites, man pages, and test suite are available here: https://github.com/andreas-gruenbacher/richacl Changes to other user-space packages for richacl: https://github.com/andreas-gruenbacher/coreutils https://github.com/andreas-gruenbacher/e2fsprogs https://github.com/andreas-gruenbacher/xfsprogs-dev https://github.com/andreas-gruenbacher/nfs-utils Please see the richacl homepage for more information: http://www.bestbits.at/richacl/ Thanks, Andreas Andreas Gruenbacher (20): vfs: Add IS_ACL() and IS_RICHACL() tests vfs: Add MAY_CREATE_FILE and MAY_CREATE_DIR permission flags vfs: Add MAY_DELETE_SELF and MAY_DELETE_CHILD permission flags vfs: Make the inode passed to inode_change_ok non-const vfs: Add permission flags for setting file attributes richacl: In-memory representation and helper functions richacl: Permission mapping functions richacl: Compute maximum file masks from an acl richacl: Permission check algorithm posix_acl: Unexport acl_by_type and make it static vfs: Cache base_acl objects in inodes vfs: Add get_richacl and set_richacl inode operations vfs: Cache richacl in struct inode richacl: Update the file masks in chmod() richacl: Check if an acl is equivalent to a file mode richacl: Create-time inheritance richacl: Automatic Inheritance richacl: xattr mapping functions richacl: Add richacl xattr handler vfs: Add richacl permission checking Aneesh Kumar K.V (2): ext4: Add richacl support ext4: Add richacl feature flag drivers/staging/lustre/lustre/llite/llite_lib.c | 2 +- fs/Kconfig | 3 + fs/Makefile | 2 + fs/attr.c | 81 +++- fs/ext4/Kconfig | 11 + fs/ext4/Makefile| 1 + fs/ext4/ext4.h | 6 +- fs/ext4/file.c | 3 + fs/ext4/ialloc.c| 11 +- fs/ext4/inode.c | 12 +- fs/ext4/namei.c | 5 + fs/ext4/richacl.c | 142 ++ fs/ext4/richacl.h | 40 ++ fs/ext4/super.c | 49 +- fs/ext4/xattr.c | 7 + fs/f2fs/acl.c | 4 +- fs/inode.c | 15 +- fs/jffs2/acl.c | 10 +- fs/namei.c | 118 - fs/posix_acl.c | 50 +- fs/richacl_base.c | 580 fs/richacl_inode.c | 333 ++ fs/richacl_xattr.c | 235 ++ fs/xattr.c | 29 +- include/linux/fs.h | 60 ++- include/linux/posix_acl.h | 13 +- include/linux/richacl.h | 208 + include/linux/richacl_xattr.h | 31 ++ include/uapi/linux/Kbuild | 2 + include/uapi/linux/fs.h | 3 +- include/uapi/linux/richacl.h| 152 +++ include/uapi/linux/richacl_xattr.h | 44 ++ include/uapi/linux/xattr.h | 2 + 33 files changed, 2157 insertions(+), 107 deletions(-) create mode 100644 fs/ext4/richacl.c create mode 100644 fs/ext4/richacl.h create mode 100644 fs/richacl_base.c create mode 100644 fs/richacl_inode.c create mode 100644 fs/richacl_xattr.c create mode 100644 include/linux/richacl.h create mode 100644 include/linux/richacl_xattr.h create mode 100644 include/uapi/linux/richacl.h create mode 100644 include/uapi/linux/richacl_xattr.h -- 2.4.3
[PATCH v18 00/22] Richacls (Core and Ext4)
Al, could you please make sure you are happy with the current version of the richacl patch queue for the next merge window? Changes since the last posting (https://lwn.net/Articles/671398/): * Some combinations of ACL entry flags were not computed correctly when ACL entries were inherited from a directory to files and directories created inside that directory. This is fixed now, with a test case covering all the flag combinations in the richacl package. * Rebases on top of v4.5-rc5. The complete patch queue is available here: git://git.kernel.org/pub/scm/linux/kernel/git/agruen/linux-richacl.git \ richacl-2016-02-22 The richacl user-space utilitites, man pages, and test suite are available here: https://github.com/andreas-gruenbacher/richacl Changes to other user-space packages for richacl: https://github.com/andreas-gruenbacher/coreutils https://github.com/andreas-gruenbacher/e2fsprogs https://github.com/andreas-gruenbacher/xfsprogs-dev https://github.com/andreas-gruenbacher/nfs-utils Please see the richacl homepage for more information: http://www.bestbits.at/richacl/ Thanks, Andreas Andreas Gruenbacher (20): vfs: Add IS_ACL() and IS_RICHACL() tests vfs: Add MAY_CREATE_FILE and MAY_CREATE_DIR permission flags vfs: Add MAY_DELETE_SELF and MAY_DELETE_CHILD permission flags vfs: Make the inode passed to inode_change_ok non-const vfs: Add permission flags for setting file attributes richacl: In-memory representation and helper functions richacl: Permission mapping functions richacl: Compute maximum file masks from an acl richacl: Permission check algorithm posix_acl: Unexport acl_by_type and make it static vfs: Cache base_acl objects in inodes vfs: Add get_richacl and set_richacl inode operations vfs: Cache richacl in struct inode richacl: Update the file masks in chmod() richacl: Check if an acl is equivalent to a file mode richacl: Create-time inheritance richacl: Automatic Inheritance richacl: xattr mapping functions richacl: Add richacl xattr handler vfs: Add richacl permission checking Aneesh Kumar K.V (2): ext4: Add richacl support ext4: Add richacl feature flag drivers/staging/lustre/lustre/llite/llite_lib.c | 2 +- fs/Kconfig | 3 + fs/Makefile | 2 + fs/attr.c | 81 +++- fs/ext4/Kconfig | 11 + fs/ext4/Makefile| 1 + fs/ext4/ext4.h | 6 +- fs/ext4/file.c | 3 + fs/ext4/ialloc.c| 11 +- fs/ext4/inode.c | 12 +- fs/ext4/namei.c | 5 + fs/ext4/richacl.c | 142 ++ fs/ext4/richacl.h | 40 ++ fs/ext4/super.c | 49 +- fs/ext4/xattr.c | 7 + fs/f2fs/acl.c | 4 +- fs/inode.c | 15 +- fs/jffs2/acl.c | 10 +- fs/namei.c | 118 - fs/posix_acl.c | 50 +- fs/richacl_base.c | 580 fs/richacl_inode.c | 333 ++ fs/richacl_xattr.c | 235 ++ fs/xattr.c | 29 +- include/linux/fs.h | 60 ++- include/linux/posix_acl.h | 13 +- include/linux/richacl.h | 208 + include/linux/richacl_xattr.h | 31 ++ include/uapi/linux/Kbuild | 2 + include/uapi/linux/fs.h | 3 +- include/uapi/linux/richacl.h| 152 +++ include/uapi/linux/richacl_xattr.h | 44 ++ include/uapi/linux/xattr.h | 2 + 33 files changed, 2157 insertions(+), 107 deletions(-) create mode 100644 fs/ext4/richacl.c create mode 100644 fs/ext4/richacl.h create mode 100644 fs/richacl_base.c create mode 100644 fs/richacl_inode.c create mode 100644 fs/richacl_xattr.c create mode 100644 include/linux/richacl.h create mode 100644 include/linux/richacl_xattr.h create mode 100644 include/uapi/linux/richacl.h create mode 100644 include/uapi/linux/richacl_xattr.h -- 2.4.3