[Samba] 4.20: case (in)sensitive is broken

Michael Tokarev mjt at tls.msk.ru
Fri Jun 7 17:21:26 UTC 2024

07.06.2024 19:27, Jeremy Allison wrote:
> On Fri, Jun 07, 2024 at 04:59:29PM +0300, Michael Tokarev via samba wrote:

>> It boils down to having wide links = yes (and unix extensions = no).
> Wide links is problematic. I'd love to just remove it :-).

I don't see anything problematic in wide links.  I'd say it's samba who
views it as problematic (just like in a few other places too), -- samba
tries to be a bit too smart here, in my opinion.

In a few places and scenarios, wide links is the only really working
solution, or at least a solution which is significantly easier than other

I'll give just an example.  Right now we're migrating an application from
one server to another, with changes on client side (so since it requires
reconfiguration of a lot of client computers, things can't be done in a
single night).  At the same time, the layout of files also changes.
So during the migration, we have two shares, one with old file layout,
and another with new.  Old layout is made by sym-linking new directories
from the new share into old share, - this way, we need to update files in
just one place and they're already updated in old place.  An alternative
would be to bind-mount a lot of stuff (linux-only feature).  But this way,
since mount id is different, samba does not see them as the same file,
and locking etc doesn't work.  Both shares are read-only, so we're not
worrying about any symlink-based or other attacks.  Without any smartness
from samba it Just Work.  But samba applies too much smartness here and
breaks things badly.


GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24.
New key: rsa4096/61AD3D98ECDF2C8E  9D8B E14E 3F2A 9DD7 9199  28F1 61AD 3D98 ECDF 2C8E
Old key: rsa2048/457CE0A0804465C5  6EE1 95D1 886E 8FFB 810D  4324 457C E0A0 8044 65C5
Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt

More information about the samba mailing list