Bug 13399 - During start up samba fails is posix acls are used
Summary: During start up samba fails is posix acls are used
Status: NEEDINFO
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Other (show other bugs)
Version: 4.8.0
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-24 03:49 UTC by William Brown
Modified: 2021-01-11 13:48 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description William Brown 2018-04-24 03:49:26 UTC
samba[26]:   invalid permissions on directory '/usr/local/samba/private/msg.sock': has 0750 should be 0700
samba[26]: [2018/04/24 13:45:11.964634,  0] ../lib/util/become_daemon.c:124(exit_daemon)

This is because I use ACLs to allow a backup operator to read the content with a default inheritance mask.

# file: msg.sock
# owner: root
# group: root
user::rwx
user:backup:r-x
group::---
mask::r-x
other::---
default:user::rwx
default:user:backup:r-x
default:group::---
default:mask::r-x
default:other::---

Because of the complexity of posix acl management, it's very hard to manage and exclude these.

A better behaviour from samba would be to determine if ACL's are present and then ignore the group setting - alternately, don't *check* the group bits because the file is owned root:root, so it's effectively the same as 700 anyway.
Comment 1 William Brown 2018-04-24 03:55:21 UTC
It looks like even if you fix this single ACL, setting ACL's at all breaks the LDAP process and other components from starting.
Comment 2 Jeremy Allison 2018-04-25 20:26:28 UTC
I have to admit this is going to be very fiddly to fix. What we have right now is simple and safe, and yours is a semi-unusual case.
Comment 3 William Brown 2018-04-25 23:34:15 UTC
(In reply to Jeremy Allison from comment #2)

You know, I don't think that's the case. Rather than looking at this as a technical issue look at it from a usability view.

The idea of this behaviour is to prevent data leaks or incorrect permissions, by preventing the service starting (effectively an alarm system).

If root:root owns the files then because root user is effectively the same as root group, then it should only matter that the ownership is correct - not the permission bits themself. The only permission bit that matters is the "everyone else" bit in that case.

So there are two solutions:

* One is to remove the check. This is an attempt at an alarm system to prevent a file/data disclosure due to an administrative mistake - when perhaps the admin has an intent we don't understand (like this situation).
* Fix the check to assert ownership is root:root *only*. From there check only the "everyone" bit. 

I think you would probably prefer the second solution. The benefit to this is that when you add posix ACLs, because they convert the group bit into the effective rights mask, but the root:root ownership stays the same. This would allows ACLs to work and samba can happily alarm if the "everyone" permission is too broad.

A prime case for removal of the check is containerisation, because you often won't have root permissions in the container, you'll get a randomised uid/gid pair. The security there comes from the namespacing, not the permission bits themself. So this is a reason to remove the check so that samba can be started as "non-root".
Comment 4 Rowland Penny 2021-01-11 13:48:25 UTC
Reading this bug report my first thought was,why does the backup system need access to msg.sock ?

From my understanding, on a Unix domain member, if you backup the Samba shares with permissions and the smb.conf , you can recreate it. You would probably have to backup the Samba database on a standalone server, but I can see no reason to backup msg.sock. Or I have I got hold of the wrong end of the stick ?