Bug 14166 - File services cannot be started when LOCKDIR is a symbolic link
Summary: File services cannot be started when LOCKDIR is a symbolic link
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.11.1
Hardware: All Linux
: P5 normal (vote)
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-21 06:01 UTC by Neil MacLeod
Modified: 2020-10-07 08:17 UTC (History)
5 users (show)

See Also:


Attachments
patches for Samba 4.12 (10.04 KB, patch)
2020-08-16 20:46 UTC, Christof Schmitt
vl: review+
Details
patches for Samba 4.11 (10.00 KB, patch)
2020-08-16 20:59 UTC, Christof Schmitt
vl: review+
Details
Patch for 4.13 (10.06 KB, patch)
2020-08-17 16:02 UTC, Volker Lendecke
metze: review+
vl: ci-passed+
Details
followup patch for 4.11 (892 bytes, patch)
2020-08-25 09:10 UTC, Guenther Deschner
vl: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Neil MacLeod 2019-10-21 06:01:19 UTC
Testing with 4.10.9 and 4.11.1.

smbd/nmbd/testparm all fail when LOCKDIR (ie. /var/lock) is a symbolic link to another directory.

smbd and nmbd will fail silently, exiting with error code 1.

testparm will exit with the message "Unable to initialize messaging context!"

This is the tail end of strace on smbd when LOCKDIR (/var/lock) is a symbolic link to /run/lock:

fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
getpid()                                = 1289
umask(000)                              = 000
mkdir("/var/lock", 0755)                = -1 EEXIST (File exists)
umask(000)                              = 000
lstat64("/var/lock", {st_mode=S_IFLNK|0777, st_size=11, ...}) = 0
exit_group(1)                           = ?
+++ exited with 1 +++
rpi22:~ # ls -la /var/lock
lrwxrwxrwx    1 root     root            11 Sep  3 10:27 /var/lock -> ../run/lock
rpi22:~ # ls -la /var/lock/
total 0
drwxr-xr-x    3 root     root            60 Sep  3 10:27 .
drwxr-xr-x   17 root     root           500 Sep  3 10:27 ..
drwxr-xr-x    2 root     root            40 Sep  3 10:27 subsys
rpi22:~ # ls -la /var/lock/subsys/
total 0
drwxr-xr-x    2 root     root            40 Sep  3 10:27 .
drwxr-xr-x    3 root     root            60 Sep  3 10:27 ..


This is not an issue with 4.19.13, and is a change of behaviour with 4.10.x and 4.11.x.

Is this by design, or a bug in which case can the old behaviour be reinstated ie. follow the symbolic link? This is breaking existing installations that are working fine with a symbolic link up to and including 4.9.13.

This is the strace from smbd on 4.9.13 when /var/lock is a symbolic link to /run/lock (smbd starts successfully):

fcntl(3, F_GETFD)                       = 0
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
getpid()                                = 1309
lstat("/var/lock", {st_mode=S_IFLNK|0777, st_size=11, ...}) = 0
lstat("/var/lock/msg.lock", {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0
lstat("/var/lock/msg.lock", {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0
lstat("/run/samba/msg.sock", {st_mode=S_IFDIR|0700, st_size=120, ...}) = 0
lstat("/run/samba/msg.sock", {st_mode=S_IFDIR|0700, st_size=120, ...}) = 0
getpid()                                = 1309
getpid()                                = 1309
openat(AT_FDCWD, "/var/lock/msg.lock/1309", O_RDWR|O_CREAT|O_NONBLOCK, 0644) = 6
fcntl(6, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = 0
read(4, "\27\247Q\321\v\373?\233", 8)   = 8
ftruncate(6, 21)                        = 0
write(6, "11186936027586602775\n", 21)  = 21
Comment 1 Andrew Bartlett 2019-10-21 06:17:25 UTC
This looks like a regression (or increased strictness) from:

commit 9f60a77e0b4c8ad06a8156ff5b5ebc5902d4ec17
Author: Christof Schmitt <cs@samba.org>
Date:   Wed Aug 29 12:04:29 2018 -0700

    lib: Fix lstat check in directory_create_or_exist
    
    The lstat check in directory_create_or_exist did not verify whether an
    existing object is actually a directory. Also move the check to only
    apply when mkdir returns EEXIST; this fixes CID 241930 Time of check
    time of use.
    
    Signed-off-by: Christof Schmitt <cs@samba.org>
    Reviewed-by: Andreas Schneider <asn@samba.org>
Comment 2 Christof Schmitt 2020-08-16 20:46:38 UTC
Created attachment 16171 [details]
patches for Samba 4.12
Comment 3 Christof Schmitt 2020-08-16 20:59:46 UTC
Created attachment 16172 [details]
patches for Samba 4.11
Comment 4 Volker Lendecke 2020-08-17 09:18:56 UTC
We should consider this for 4.13 as well. The 4.12 patch applies and builds against 4.13 as well if you use "git am -3".
Comment 5 Karolin Seeger 2020-08-17 11:22:58 UTC
Pushed to autobuild-v4-{13,12,11}-test.
Comment 6 Volker Lendecke 2020-08-17 14:38:13 UTC
Taking the bug again. 4.13 did not make it, I'll send it through another gitlab-ci before appending the proper patch here. Apologies for trying to cut corners.
Comment 7 Volker Lendecke 2020-08-17 16:02:17 UTC
Created attachment 16173 [details]
Patch for 4.13

https://gitlab.com/samba-team/devel/samba/-/pipelines/178757903
Comment 8 Karolin Seeger 2020-08-18 09:40:58 UTC
Pushed to autobuild-v4-13-test.
Comment 9 Guenther Deschner 2020-08-25 09:10:34 UTC
Created attachment 16182 [details]
followup patch for 4.11
Comment 10 Karolin Seeger 2020-08-25 11:22:21 UTC
(In reply to Guenther Deschner from comment #9)
Pushed to autobuild-v4-11-test.
Comment 11 Karolin Seeger 2020-08-31 07:36:13 UTC
(In reply to Karolin Seeger from comment #10)
Pushed to v4-11-test.
Closing out bug report.

Thanks!
Comment 12 Samba QA Contact 2020-10-06 07:17:08 UTC
This bug was referenced in samba v4-11-stable (Release samba-4.11.14):

051a9021d50a1303bf6757811622cf83390ad339
Comment 13 Samba QA Contact 2020-10-07 08:17:06 UTC
This bug was referenced in samba v4-12-stable (Release samba-4.12.8):

0797eef2901cc0b8d1fcc11f368285cfcf1b0400
492213aff41e0ad0794f1b1fce0120d8991825c2