Behaviour mismatch between "store dos attributes" and "map archive" from man smb.conf(5)
jra at samba.org
Thu May 14 00:55:08 UTC 2020
On Thu, May 14, 2020 at 01:36:12AM +0200, Michael Adam wrote:
> Right, and this is done unconditionally in open_file_ntcreate(),
> I mean without checking lp_store_dos_attributes() first. So the
> manpage is clearly wrong. store-dos-attributes disables none of
> the map options. We only see the effect for map archive since
> the other three default to "no" anyway...
> What I am wondering is this:
> If the file is created with SEC_RIGHTS_FILE_ALL, shouldn't it
> get execute permissions, even if "map archive = no"?
> After all, "map archive = no" does not prevent execute from
> being set, it just doesn't set it because of archive...
No. SEC_RIGHTS_FILE_ALL is only to do with the access permissions
on the handle, not the permissions on the file.
> And this should be true without vfs_acl_xattr, but afaict also
> with the module, when system_acls are not ignored (i.e. when the
> acls are still mapped to posix acls).
> So I am missing the piece where the actual desired permissions
> from the create call are factored into the resulting unix
It's just passed down directly from the mode bits that
are created in open_file_ntcreate().
mode_t unx_mode = unix_mode(conn, new_dos_attributes | FILE_ATTRIBUTE_ARCHIVE,
-> open_file(..., unx_mode, ...)
-> fd_open_atomic(..., unx_mode, ...)
-> fd_open(..., unx_mode, ...)
-> non_widelink_open(..., unx_mode, ...)
-> SMB_VFS_OPEN(..., unx_mode, ...)
-> open(name, flags, unx_mode)
> Well, at least the manpage describes some original intentions
> as it seems. The current behavior is at least surprising when
> the man page text is taken into account.
Yep. The man page is wrong here.
> Of course, thanks!
> Two questions remain:
> - Should we implement the behavior stated in the manpage?
> (I think yes!)
Hmmmm. Maybe. Be careful of changing things here,
it may not be what users expect.
> - Why is the x-bit not set when SEC_FILE_ALL is requested in create?
'cos SEC_FILE_ALL is bugger all to do with on-disk
file permissions. That's a handle access mode (think
fd, not file). You have to set a security descriptor for that.
Remember there's no atomic open_with_posix_acl() call
in POSIX. So you get what is inherited from the parent
directory (if it's set up that way). Samba then overlays
(non-atomically, as there's no other way in POSIX) and
security descriptor set on the file after it's created.
More information about the samba-technical