RFC: smbcacls fails with windows with SMB2 (succeeds with SMB1 only)

Noel Power nopower at suse.com
Thu Jul 20 13:30:14 UTC 2017


Hi

While testing my own smbcacls changes against master I saw some
unexpected failures. After some investigation I see the same problems
with the normal master version of smbcacls. The problem is observed when
removing/allowing inherited ACE(s)

The setup I have is simple, just a directory 'oi_dir' and a sub
directory within 'oi_dir/oi_nested_dir'

  ./bin/smbcacls -UAdministrator%xyz  --list //192.168.100.15/Temp \\oi_dir

  REVISION:1
  CONTROL:SR|DI|DP
  OWNER:BUILTIN\Administrators
  GROUP:TESTDOMAIN1\Domain Users
  ACL:TESTDOMAIN1\Administrator:ALLOWED/OI|CI|I/FULL
  ACL:BUILTIN\Administrators:ALLOWED/OI|CI|I/FULL

  ./bin/smbcacls -UAdministrator%xyz  -list //192.168.100.15/Temp
\\oi_dir/oi_nested_dir

  REVISION:1
  CONTROL:SR|DI|DP
  OWNER:BUILTIN\Administrators
  GROUP:TESTDOMAIN1\Domain Users
  ACL:TESTDOMAIN1\Administrator:ALLOWED/OI|CI|I/FULL
  ACL:BUILTIN\Administrators:ALLOWED/OI|CI|I/FULL
  ACL:Everyone:ALLOWED/OI|CI|I/FULL


Then removing inherited ACE(S)

  ./bin/smbcacls  -UAdministrator%xyz  --inherit=remove 
//192.168.100.15/Temp \\oi_dir/oi_nested_dir
  Failed to file info \oi_dir\oi_nested_dir: NT_STATUS_ACCESS_DENIED

NOTE: error above

  ./bin/smbcacls -UAdministrator%1Paiste4me  -list //192.168.100.15/Temp
\\oi_dir/oi_nested_dir
  REVISION:1
  CONTROL:SR|PD|DP
  OWNER:BUILTIN\Administrators
  GROUP:TESTDOMAIN1\Domain Users

And then allow inherited ACE(s) from parent dir


  ./bin/smbcacls  -UAdministrator%1Paiste4me  --inherit=allow 
//192.168.100.15/Temp \\oi_dir/oi_nested_dir
  Failed to file info \oi_dir\oi_nested_dir: NT_STATUS_ACCESS_DENIED

NOTE: error again above

  ./bin/smbcacls -UAdministrator%1Paiste4me  -list //192.168.100.15/Temp
\\oi_dir/oi_nested_dir
  REVISION:1
  CONTROL:SR|DP
  OWNER:BUILTIN\Administrators
  GROUP:TESTDOMAIN1\Domain Users
  ACL:Everyone:ALLOWED/0x0/FULL
  ACL:BUILTIN\Administrators:ALLOWED/0x0/FULL
  ACL:TESTDOMAIN1\Administrator:ALLOWED/0x0/FULL

However the expected ACE(S) for a directory would be

  REVISION:1
  CONTROL:SR|DI|DP
  OWNER:BUILTIN\Administrators
  GROUP:TESTDOMAIN1\Domain Users
  ACL:TESTDOMAIN1\Administrator:ALLOWED/OI|CI|I/FULL
  ACL:BUILTIN\Administrators:ALLOWED/OI|CI|I/FULL
  ACL:Everyone:ALLOWED/OI|CI|I/FULL

NOTE: the presence of the inherited container related ACE(s)

This problem is related to SMB2, SMB1 works fine. Also note: this
problem only occurs with a windows server (I tested with win2k12) and
SMB & SMB2 protocols work fine with smbd server

smbcalcs.c:

uint16_t get_fileinfo(...)

    status = cli_ntcreate(cli, filename, 0, CREATE_ACCESS_READ,
                  0, FILE_SHARE_READ|FILE_SHARE_WRITE,
                  FILE_OPEN, 0x0, 0x0, &fnum, NULL);

    status = cli_qfileinfo_basic(cli, fnum, &mode, NULL, NULL, NULL,
                     NULL, NULL, NULL);

The cli_qfileInfo_basic (and the associated
FILE_FINFO/SMB2_FILE_ALL_INFO SMB2 request) fail and thus the file
attributes returned and not correct and attempts to identify directories
fail.

Looking at smb2 client related traces (e.g. for smbclient) such requests
seems generally to use FILE_READ_ATTRIBUTES instead of
CREATE_ACCESS_READ for opening the request file. Making the same change
here also seems to work.

However since we only use this get_fileinfo function to return the file
attributes (and actually only really to tell if the file is a directory)
it seems the cli_qfileinfo_basic is unneccesary. Instead of changing the
permissions I attach a patch to just remove the use of
cli_qfileinfo_basic and get the file attributes instead from the
cli_ntcreate call

thanks,

Noel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-s3-utils-smbcacls-failed-to-detect-DIRECTORIES-using.patch
Type: text/x-patch
Size: 2299 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170720/b29b34c6/0001-s3-utils-smbcacls-failed-to-detect-DIRECTORIES-using.bin>


More information about the samba-technical mailing list