Questions about smbd option "strict rename"

[Ralph Boehme]

Hi!

I stumbled upon an inconsitency in "strict rename".

The following set of patches added this option and a test:

---8<---
commit 035fd7200d8a025cdb8bfae30c264757aa3cb193
Author: Volker Lendecke <vl at samba.org>
Date:   Thu Sep 25 01:30:33 2014 +0200

    s3:smbd: Don't rename a dir with files open underneath

    This is an EXPENSIVE check. We'll have to guard this with an option

    Signed-off-by: Volker Lendecke <vl at samba.org>
    Reviewed-by: Jeremy Allison <jra at samba.org>
    Reviewed-by: Stefan Metzmacher <metze at samba.org>

commit 5f60dcc38ca275aedeb1d67611b5acf9b26361d5
Author: Jeremy Allison <jra at samba.org>
Date:   Fri Oct 24 13:57:04 2014 -0700

    selftest:Samba3: use "strict rename = yes"

    Signed-off-by: Jeremy Allison <jra at samba.org>
    Reviewed-by: Stefan Metzmacher <metze at samba.org>

commit b0a434386dc2f77df89811bc3f56c4cc7fb7b16c
Author: Jeremy Allison <jra at samba.org>
Date:   Fri Oct 24 13:57:04 2014 -0700

    s3:param: Add new option "strict rename".

    Control whether smbd can rename directories containing
        open files. Defaults to "no" (meaning we *can* do
	    such renames).

    Signed-off-by: Jeremy Allison <jra at samba.org>
    Reviewed-by: Stefan Metzmacher <metze at samba.org>
---8<---

According to the commit message and the manpage description, "strict
rename = no" means we won't check for open files when we do a
directory rename.

If this is correct, we have two bugs:

- "strict rename = no": doesn't work, opens are always checked,
  regardless of the setting of "strict rename".  can_rename(), the
  function where we do this check when renaming a directory, is
  missing a check for lp_strict_rename() or similar.

- "strict rename = yes": the function called to do the actual check
  for open files is file_find_subpath() which only checks for opens in
  that process and doesn't traverse locking.tdb

In private conversation metze suggested that "strict rename" is
supposed to have completely different semantics:

- "strict rename = no": check for opens, but only in the current
  process, avoids expensive locking.tdb traversal, deny rename if open
  found

- "strict rename = yes": check for opens by traversing locking.tdb,
  deny rename if open found

Either way, I can provide fixes, but first we should agree upon the
semantics of "strict rename". :)

I am currently pursuing this case, because not allowing directory
renames with open files is a major pita for OS X users. OS X expects
POSIX rename semantics and that's what OS X SMB server implements. I
know this contradicts MS-SMB2/FSA.

"strict rename = no" with the semantics described in the manpage,
would give OS X users an easy workaround. An alternative would be
something like my patch attached to the bugreport that tracks this
problem for OS X users:

<https://bugzilla.samba.org/show_bug.cgi?id=11065>
<https://attachments.samba.org/attachment.cgi?id=10648>

Cheerio!
-slow

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de,mailto:kontakt@sernet.de