IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This is a first testparm/lp_load test that runs testparm on a couple
of configuration files. The main purpose for now is to test the options
that have special handlers (to check whether the handlers succeed).
In particular, all the Macro expansions that are available via
alloc_sub_basic() are tested with the include handler. This is to
catch such crashbugs as #5548 where %m expansion led to a segfault.
The tests now are very simple. Just check if testparm completes
successfully on the given config files. This can (and should) be
elaborated in the future.
Michael
Without this the changed checks in can_delete_file_in_directory give DELETE
access where there is none. So we can end up granting the ntcreate&x preparing
the unlink where we should not, which leads to a NT_STATUS_ACCESS_DENIED at
close time later, which in turn does *not* give the access denied error message
in the Windows GUI.
can_delete_file_in_directory will grant access now by looking at the directory
permissions.
With at least NFSv4 ACLs around the write permission for the owner is a bogus
check if we can delete a file in a directory. Like in Windows, there are two
ways which can grant us such: First, the DELETE permission on the file itself,
or if that does not help, the DELETE_CHILD permission on the directory. It
might be a bit more code that runs, but essentially we should end up with the
same set of syscalls in the non-acl case.
This reverts commit b1afb31f3cadd4749bf6e3eb5d8935588bf8ebfc.
This one is very strange: I need to investigate why valgrind showed it as
leaking, and why in my initial tests this did not fail.
(cherry picked from commit 24730f5981efb920811e7929a9483bd72bb0984c)
Remove the user from BUILTIN\Administrators at the end of the tests.
Note: BUILTIN\Administrators is not deletet at the end because that
functionality is not implemented.
Michael
It breaks RPC-SAMBA3-GETUSERNAME for reasons I have not quite
understood yet. Somhow loosing rights fails when the user
belogns to BUILTIN\Administrators at some point.
Michael
