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