FLAG_CASELESS_PATHNAMES/SMBFLG_CASELESS in set_current_service()
Stefan Metzmacher
metze at samba.org
Wed Jun 13 08:17:31 UTC 2018
Hi Jeremy,
hi Steve,
I'm wondering about the mess regarding conn->case_sensitive we have in
set_current_service(). Is this really needed?
Windows servers ignore FLAG_CASELESS_PATHNAMES completely,
but we do some magic just for smbclient and cifs.ko.
Only [lib]smbclient supports changing the flag on a per request basis,
but is it really used in practice?
Can't we just set conn->case_sensitive based on, smb1 unix extension
being used on the share?
Does it really make sense to have an 'case sensitive' smb.conf option?
Do we really want to have conn->case_sensitive = true for non-unix
extensions clients?
Do we really need a 'nocase'/'ignorecase' mount option?
In libsmbclient it seems that SMBC_server_internal() will
use cli_get_fs_attr_info() and set may fill in
FILE_CASE_SENSITIVE_SEARCH if the server supports it
(samba does).
To me it seems that smbclient and libsmbclient behave differently,
because smbclient doesn't use SMBC_server[_internal]()
and doesn't call cli_get_fs_attr_info().
smbclient has the "case_sensitive" operation to toggle
FILE_CASE_SENSITIVE_SEARCH, which later leads to
FLAG_CASELESS_PATHNAMES=0.
This makes it really difficult to progress on my impersonation patches,
because we don't have the per request FLAG_CASELESS_PATHNAMES available
when we restore the impersonation based on just the connection/vuid.
Can this all be done by FILE_FLAG_POSIX_SEMANTICS/ATTR_POSIX_SEMANTICS?
Where we also have req->posix_pathnames and UCF_POSIX_PATHNAMES?
Any ideas how to move forward here?
Thanks!
metze
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20180613/bc1bf685/signature-0001.sig>
More information about the samba-technical
mailing list