https://bugs.kde.org/show_bug.cgi?id=40892
Harald Sitter <sit...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sit...@kde.org
--- Comment #4 from Harald Sitter <sit...@kde.org> ---
Doc dump:
https://www.samba.org/samba/docs/current/man-html/smbcacls.1.html
https://www.samba.org/samba/docs/current/man-html/sharesec.1.html
libsmbc's smbc_getxattr respectively setxattr would be used. smbc_listxattr
seems largely pointless, for some reason it always returns system.* no matter
the server.
internally that drives through the IPC$ share, for some reason that entirely
fails auth when kerberos is enabled though -> likely needs reworking of
auth.cpp to "manually" try with and without kerberos or something. this happens
with samba and windows hosts. all a bit strange
xattrs are as follows: (all + variants translate SIDs to pretty string, without
+ they are SIDs - SIDs are entirely pointless for libsmbc I think, we can't do
anything with them as there is no API that accepts them)
system.nt_sec_desc.owner+ => pretty name of owner "$SCOPE\$name (e.g. SMITH\me)
system.nt_sec_desc.group+ => pretty name of group "$SCOPE\$name" (e.g. Unix
Group\me)
system.nt_sec_desc.acl.*+ => all ACLs separated by comma (e.g.
SMITH\me:0/0/0x001f01ff,Unix Group\me:0/0/0x001f01ff,Unix
Group\www-data:0/0/0x001f01ff,Unix
Group\me:0/0/0x001200a9,\Everyone:0/0/0x001200a9)
ACLs are of the form <sid>:<type>/<flags>/<mask>
type => 0 for allowed, 1 for forbidden
flags => kinda undocumented? (see [1]) also on smbcacls manpage, not in any
header?
mask => also undocumented? also context in [1]
biggest concern right now is getting a hold of the flags and masks defines,
since they only seem to be available internally for samba I am not sure how
exactly libsmbc expects one to use the output of getxattr. perhaps I am missing
something?
Windows example acl*:
WINDEV1905EVAL\puny:1/0/0x001f01ff,WINDEV1905EVAL\puny:0/16/0x001f01ff,NT
AUTHORITY\SYSTEM:0/16/0x001f01ff,BUILTIN\Administrators:0/16/0x001f01ff,WINDEV1905EVAL\User:0/16/0x001f01ff
NB: for linux ACLs are the file system ACL (in so far as there are ACLs on the
file system). on windows it seems a bit unclear but certainly looks like one
gets both file and share ACL, the example above is of a file in dir that is
shared with puny having only read access on the share level but full control
the FS level. needs more inspection.
to model all this one could probably rely on KACL which implements POSIX ACL
and should be good enough for the most relevant aspect of controlling R/W/X
bits.
Buuuut that'd be distinctly less fine grained than windows still (e.g. windows
has distinct permissions for deleting an object or changing its permissions),
it may entirely make sense to forego KACL and by extension the stock KIO
permissions tab and instead implement a bespoke dialog in
kdenetwork-filesharing that fully models windows ACLs.
another option would be extending or abstracting KACL, which would only really
make sense if dolphin wants to have first class windows support, in which case
it needs to model NTFS ACLs anyway and we could share the implement. at that
point we could still lift a bespoke model out of kdenetwork-filesharing though
to bootstrap the KIO work. I find that option rather appealing.
for the KACL case as I understand it one can simply feed KACL stringy POSIX
ACLs.
i.e.
<type>:<object>:<mask>
type => u/g/o/m
object => uid/gid/uname/gnmae
mask => rwx/0
also see https://linuxgazette.net/152/prestia.html
[1]
https://github.com/samba-team/samba/blob/2d5facc95478801580eb52d4d4441660c5fa2697/librpc/idl/security.idl#L480
--
You are receiving this mail because:
You are watching all bug changes.
