Behaviour mismatch between "store dos attributes" and "map archive" from man smb.conf(5)

[Michael Adam]

On 2020-05-13 at 11:42 -0700, Jeremy Allison via samba-technical wrote:
> On Wed, May 13, 2020 at 04:42:30PM +0530, Anoop C S via samba-technical wrote:
> > Hi,
> > 
> > Following is a question I have regarding the interaction between two
> > smb.conf parameters mentioned in the $subject. It can very well be a
> > misunderstanding from my side.
> > 
> > We have both "store dos attributes" and "map archive" set to 'yes' for
> > default install. But according to its description man smb.conf(5):
> > 
> > store dos attributes (S)
> > 
> > . . .When this parameter is set it will override the parameters map
> > hidden, map system, map archive and map readonly and they will behave
> > as if they were set to off. . .
> > 
> > My question is around smb2.read.access torture test where it tries to
> > open a file with different access flags including SEC_FILE_EXECUTE.
> > When run against a share with "map archive = no"(or implicitly assumed
> > by "store dos attributes" set) we cannot expect execute bit to be
> > present for the owner. Thanks to Ralph(and Michael, Guenther) who
> > helped me understand basic selftest architecture which adds
> > vfs_acl_xattr in [global] section for many torture tests including
> > smb2.read making it pass with `make test`.
> > 
> > Nevertheless, leaving "store dos attributes" at its default, why would
> > smbd create file with execute bit set for the owner? I hope its not
> > because of some umask calculation done at the end outside Samba because
> > if that's the case I would expect it to be set even when "map archive"
> > is explicitly set to 'no'. There seems to be some mismatch between
> > assumed and real behaviour.
> 
> Quick check - does your smb.conf have "obey pam restrictions = yes"
> set anywhere ?
> 
> That can mess up our mask calculations. Let me know that parameter
> is set to "no" before I dig in further :-).

"obey pam restrictions" was certainly set to the default, i.e.  "no".
We used a mostly default config.

The interesting bit is that smb2.read passes with "store dos
attributes" and the "map foobar" options set to default, and
we see the file get execute perms. But if we explicitly set
"map archive" to "no" (which according to the man page should
be the effect with "store dos attributes = yes"), then the test
fails at source4/torture/smb2/read.c:270, expecting execute perms.

Now the test is run in samba selftest only against a share with
the "acl_xattr" vfs module enabled. That obviously passes. with
any "map foobar" setting.

So the question is:

- Does store "dos attributes" not completely disable "map
  archive" as claimed in the manpage?

- Or is the disabling of "map archive" doing too much in not
  setting the execute bit when it should? After all the call
  to torture_smb2_testfile() in source4/torture/smb2/read.c:245
  should create the file with SEC_RIGHTS_FILE_ALL, which should
  include execute perms. So is the execute somehow masked away?
  (We played with setting masks to allow all bits too, that did
  not change anything.)

We wanted to raise it here before digging deeper since it is
quite possible that we are missing something that is more obvious
to some. :-)

Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20200514/700fce5b/signature.sig>