impersonation patchset part2 (Re: FLAG_CASELESS_PATHNAMES/SMBFLG_CASELESS in set_current_service())

[Stefan Metzmacher]

Am 15.06.2018 um 01:08 schrieb Jeremy Allison via samba-technical:
> On Thu, Jun 14, 2018 at 08:01:13PM +0200, Stefan Metzmacher wrote:
>>>>>> 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?
>>>>>
>>>>> No.
>>>>
>>>> So we can really remove smbc_setOptionCaseSensitive() ?
>>>> And the "case_sensitive" smbclient command?
>>>
>>> Yes, I think we can.
>>
>> And don't worry about the ABI change?
> 
> What are our options here ? smbc_setOptionCaseSensitive()
> will become a no-op, so we either leave it and document
> it's not useful, or remove it and uprev the library major
> number I think.
> 
>>>>> POSIX opens (SMB1 global switch or SMB3 POSIX create context)
>>>>> always mean case sensitive.
>>>>
>>>> Good.
>>>>
>>>>>> Can this all be done by FILE_FLAG_POSIX_SEMANTICS/ATTR_POSIX_SEMANTICS?
>>>>>> Where we also have req->posix_pathnames and UCF_POSIX_PATHNAMES?
>>>>>
>>>>> Yeah, I think so - see above.
>>>>>
>>>>>> Any ideas how to move forward here?
>>>>>
>>>>> Does my plan work ? The only issues I can see are when we're
>>>>> running on a Linux system that actually *has* a case-insensitive
>>>>> filesystem underneath (XFS or ZFS mounted in case-insensitive mode).
>>>>
>>>> Then the filesystem should not announce FILE_CASE_SENSITIVE_SEARCH.
>>>
>>> Yes, that makes sense. The client can then know that
>>> even if it asks for POSIX extensions it will not get
>>> case-sensitive pathnames.
>>
>> Should we keep the "case sensitive" option to control this?
>> Or should we better remove it completely.
> 
> I think we keep it. That way, even on a case-sensitive filesystem
> we can set "case sensitive = yes/default case = upper" to
> preserve the large directory optimization.
> 
>> And autodetect FILE_CASE_SENSITIVE_SEARCH from the local filesystem
>> or add a new separate option for it?
> 
> What option name are you thinking of here ?
> 
>> I found it, during make_connection_snum() we don't have
>> conn->origpath setup while calling change_to_user(),
>> so I use a conn->tcon_done = true at the end of make_connection_snum()
>> and only try chdir_current_service() from chane_to_user().
>>
>> The patches didn't pass autobuild, but I haven't checked yet if
>> it was just a flakey test again.
> 
> Wow, another really interesting patchset. You're on a roll here :-).

Ok, this one is reviewed by Ralph and passed autobuild a few times.
The most important changes are:
[PATCH 12/52] smbd: make it possible to call vfs_ChDir(conn,
conn->cwd_fname);
[PATCH 13/52] smbd: let create_conn_struct_as_root() fill in
 conn->origpath
[PATCH 19/52] smbd: call chdir_current_service() in
 change_to_user_internal() and pop_conn_ctx()

+       /*
+        * Check if the current context did a chdir_current_service()
+        * and restore the cwd_fname of the previous context
+        * if needed.
+        */
+       if (current_user.done_chdir && ctx_p->need_chdir) {
+               int ret;
+
+               ret = vfs_ChDir(ctx_p->conn, ctx_p->conn->cwd_fname);
+               if (ret != 0) {
+                       DBG_ERR("vfs_ChDir() failed!\n");
+                       smb_panic("vfs_ChDir() failed!\n");
+               }
+       }

I'll push that tomorrow.

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/20180617/1d0685a0/signature.sig>