Looks like we do not have self-tests for smbcacls

Noel Power nopower at suse.com
Fri Aug 4 16:49:58 UTC 2017

On 04/08/17 04:45, Andrew Bartlett wrote:
> On Thu, 2017-08-03 at 12:41 +0100, Noel Power via samba-technical
> wrote:
>> And another version.....
> Thanks.  This is getting much closer, and looks much more like our
> other tests. 
> Can you please look at source4/dsdb/tests/python/ldap.py for an example
> of how to do the command-line parsing and credentials handling?
> It is important that we don't introduce new command-line syntax, the
> rest of Samba uses -U, not -u for example.
sorry that credential handling does not seem to work, it seems to expect
s4 code/environment as it call

raceback (most recent call last):
  File "/usr/lib64/python2.7/runpy.py", line 174, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib64/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/data/samba-back/bin/python/samba/subunit/run.py", line 697, in
    TestProgram(module=None, argv=sys.argv, stdout=sys.stdout)
  File "/data/samba-back/bin/python/samba/subunit/run.py", line 535, in
  File "/data/samba-back/bin/python/samba/subunit/run.py", line 594, in
  File "/data/samba-back/bin/python/samba/subunit/run.py", line 603, in
  File "/usr/lib64/python2.7/unittest/loader.py", line 130, in
    suites = [self.loadTestsFromName(name, module) for name in names]
  File "/usr/lib64/python2.7/unittest/loader.py", line 91, in
    module = __import__('.'.join(parts_copy))
  File "/data/samba-back/bin/python/samba/tests/blackbox/smbcacls.py",
line 49, in <module>
    creds = credopts.get_credentials(lp)
  File "/data/samba-back/bin/python/samba/getopt.py", line 209, in
samba.NTSTATUSError: (-1073741606, 'Configuration information could not
be read from the domain controller, either because the machine is
unavailable or access has been denied.')

it seems get_credentials calls credentials_set_machine_account, the
associated required tdb(s) and configuration etc. seem too restrictive
for my requirements so I've removed the convenience main function to
avoid this mess

On 03/08/17 20:46, Uri Simchoni wrote:
> Sorry for not being specific enough. I was referring to patch 3/4:
>> @@ -229,18 +234,22 @@ ACL:<sid or name>:<type>/<flags>/<mask>
>>         determine the type of access granted to the SID. </para>
>>         <para>The type can be either ALLOWED or DENIED to allow/deny access
>> -       to the SID. The flags values are generally zero for file ACEs and
>> -       either 9 or 2 for directory ACEs.  Some common flags are: </para>
>> +       to the SID.</para>
>> +
>> +       <para>The flags field defines how the ACE should be considered when
>> +       performing inheritance. <command>smbcacls</command> uses these flags
>> +       when run with <parameter>--propagate-inheritance</parameter>.</para>
> Everything written about the flags is true, and the previous text is
> admittedly bad. However, IMHO, we should add the role those flags play
> when later creating new files, not only when modifying an ACL. When
> settings the ACL of an empty dir via smbcacls, one should carefully
> consider the flags, even though there's nothing to propagate.
Uri I've added a small para to additionally mention file/directory
creation, not sure if it is enough, I'd happily take on board any more
suggestions re. wording and verbage for that. Thing to note though is
that just because there are inheritance related ACE(s) on the parent
directory doesn't mean that whatever creates the file has to honour it.
E.g. cygwin on windows happily breaks the inheritance and creates files
with explicit ACE(s). Breaking inheritance is perfectly legal, there is
even a button for doing it from the explorer file/dir properties dialog


More information about the samba-technical mailing list