samba - Feb 2022 - Great article on Samba symlink fixes at Linux Weekly News !

OK, so my question is if all the internal functions have been switched 
to use file handles rather than paths, how is it possible to re-enable SMB1?



On 2/10/22 11:05, Jeremy Allison via samba wrote:
> https://lwn.net/Articles/884052/
> 
> It's a subscriber-only article for now, but
> lwn opens them up to general readers after
> two weeks. It's worth subscribing to read
> (IMHO of course :-). Full disclosure, I
> reviewed the article for technical accuracy.
> 
> Cheers,
> 
> Jeremy.
>

On 2/13/22 17:55, Patrick Goetz via samba wrote:
> OK, so my question is if all the internal functions have been switched 
> to use file handles rather than paths, how is it possible to re-enable 
> SMB1?
just

   handle = open(path)

and from then on use the handle. Of course the problem is doing the 
"open" symlink race safe, so in real Samba code we don't use
open(2)
directly, but the complex Samba function non_widelink_open().

-slow

-- 
Ralph Boehme, Samba Team                 https://samba.org/
SerNet Samba Team Lead      https://sernet.de/en/team-samba
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20220213/997490b7/OpenPGP_signature.sig>

On Sun, Feb 13, 2022 at 10:55:11AM -0600, Patrick Goetz via samba
wrote:
>OK, so my question is if all the internal functions have been switched 
>to use file handles rather than paths, how is it possible to re-enable 
>SMB1?
We use stat (path-based) (soon to be statx) to do a quick test for
existence (this can be raced), but as soon as we are gathering data
to return to the client we open using O_PATH (on Linux at least)
and use handle-based functions which cannot be raced. There is
no guarentee of atomicity of existence in the filesystem (a object
can be created or deleted by another process at any time) so
the quick check isn't a security problem.

All re-enabling SMB1 means is that we have to do many, many
more opens then we do in SMB2. For SMB1 every time the client
sends a pathname to query or modify we must open the target
internally and then close again afterwards.

The protect against races code is inside the open code path,
which is expensive.

In SMB2 the client will explicitly request an open and then
use the returned handle for all queries/modifications.