Ralph Böhme
2016-Aug-18 10:40 UTC
[Samba] Issue with acl_xattr:ignore system acls in 4.5rc2
Hi Michael, On Thu, Aug 18, 2016 at 11:42:12AM +0200, Michael Adam wrote:> From reading the original post, I get the impression > that the problem is associated to the share root directory.nope. It will happen with just any directory or file created from a non SMB client, eg mkdir|touch (or NFS, ...) on the server. It is also associated with files or directories created from Windows client where the parent directory for some reason lacks inheritable ACEs (because eg the admin relied on POSIX mode for some basic permissions).> There is of cours a chicken-and-egg problem here. > > And my wild guess is that this could be fixed with setting > a proper share acl. (use the sharesec command). > Maybe we must also/alternatively put a different xattr-acl for > the share root.Just adding inheritable (NT ACL xattr) ACEs to the share root directory indeed fixes the problem for SMB clients, but not for stuff created on the server. Cheerio! -slow
Michael Adam
2016-Aug-18 10:59 UTC
[Samba] Issue with acl_xattr:ignore system acls in 4.5rc2
On 2016-08-18 at 12:40 +0200, Ralph Böhme wrote:> Hi Michael, > > On Thu, Aug 18, 2016 at 11:42:12AM +0200, Michael Adam wrote: > > From reading the original post, I get the impression > > that the problem is associated to the share root directory. > > nope. It will happen with just any directory or file created from a > non SMB client, eg mkdir|touch (or NFS, ...) on the server.Sure. But that is works-as-designed, imho. Creating should only be done via smb in this case. All else is invalid for this config and expected to disturb behavior. The base directory has to be created externally, though, and in order to give initial access, there needs to be an ACL (xattr/share) on the base dir. Hence this is different.> It is also associated with files or directories created from Windows > client where the parent directory for some reason lacks inheritable > ACEs (because eg the admin relied on POSIX mode for some basic > permissions).Relying on posix mode is plain wrong usage when 'ignore system acls = yes'.> > There is of cours a chicken-and-egg problem here. > > > > And my wild guess is that this could be fixed with setting > > a proper share acl. (use the sharesec command). > > Maybe we must also/alternatively put a different xattr-acl for > > the share root. > > Just adding inheritable (NT ACL xattr) ACEs to the share root > directory indeed fixes the problem for SMB clients, but not for stuff > created on the server.I can only repeat: Creating stuff with other means than SMB is invalid usage when 'inherit system acls = true', imho. We may discuss a 'strict' and 'non-strict' mode to that. In order to offer backwards compatibility to old broken or at least inconsistent behavior? Cheers - Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: <http://lists.samba.org/pipermail/samba/attachments/20160818/15fa07c2/signature.sig>
Ralph Böhme
2016-Aug-18 11:11 UTC
[Samba] Issue with acl_xattr:ignore system acls in 4.5rc2
On Thu, Aug 18, 2016 at 12:59:15PM +0200, Michael Adam wrote:> On 2016-08-18 at 12:40 +0200, Ralph Böhme wrote: > > Hi Michael, > > > > On Thu, Aug 18, 2016 at 11:42:12AM +0200, Michael Adam wrote: > > > From reading the original post, I get the impression > > > that the problem is associated to the share root directory. > > > > nope. It will happen with just any directory or file created from a > > non SMB client, eg mkdir|touch (or NFS, ...) on the server. > > Sure. But that is works-as-designed, imho.I agree, but it did work that way and with 4.5 now workinging-as-designed we will break existing setups.> Creating should only be done via smb in this case. > All else is invalid for this config and expected > to disturb behavior.Well yes, we even document it in the manpage: If you only access the data via Samba you might set this to yes to achieve better NT ACL compatibility.> > It is also associated with files or directories created from Windows > > client where the parent directory for some reason lacks inheritable > > ACEs (because eg the admin relied on POSIX mode for some basic > > permissions). > > Relying on posix mode is plain wrong usage when > 'ignore system acls = yes'.agreed, but it worked with previous versions, it will suddenly stop working with 4.5.> > > There is of cours a chicken-and-egg problem here. > > > > > > And my wild guess is that this could be fixed with setting > > > a proper share acl. (use the sharesec command). > > > Maybe we must also/alternatively put a different xattr-acl for > > > the share root. > > > > Just adding inheritable (NT ACL xattr) ACEs to the share root > > directory indeed fixes the problem for SMB clients, but not for stuff > > created on the server. > > I can only repeat: Creating stuff with other means than SMB > is invalid usage when 'inherit system acls = true', imho.indeed. So leave as is and add better documentation of this change to the release notes? Cheerio! -slow