while testing ACL support for my containers filesystem, I get this:
:~# setfattr -n security.test -v test2 test.txt
setfattr: test.txt: Operation not permitted
I’m thinking it may be a problem with container privilege to modify specific filesystem attributes, but I’m not really sure how to verify this or how to go about fixing it.
I remember dimly having this kind of problem with a container based on some member of the Fedora family (Centos I think), never on Ubuntu. Had to do some hoopla with privileged container, preferred to switch to Ubuntu finally.
Do you use an Ubuntu container ?
The security xattrs are protected so only real root may write them.
I seem to remember samba having an alternate way to store that data (through some ldb file or something) which lifts the requirement for security xattr writing.
Sweet I feel dumb, It works with a privileged container. Are there security risks associated with a privileged container that might make it worth it to look into samba’s alternative way to store security data.
I think you were thinking of:
posix:eadb = /usr/local/samba/private/eadb.tdb
“This will place all extra file attributes (NT ACLs, DOS EAs, streams, etc), in that tdb”
There’s an efficiency hit doing it this way, but if there’s a security hit on a privileged container it would be good to evaluate any trade offs.
yes as said already containers are not privileged by default. There is certainly a security impact on setting a container privileged. It’s a real risk for your host if the container is breached. It has been said that the risk is different if your host is Ubuntu or it’s a member of Fedora family, because LXD is designed for Apparmor and it’s not used (I think, I have no great experience) in Fedora/Redhat/Centos.
BTW, I was wrong indeed about a difference between Ubuntu and Fedora, I remember now that I found that rpm was using a setfattr while apt is not, that’s why some utilities could not be installed at the time in an unprivileged Centos container while it was possible in an Ubuntu unprivileged container (I think it was tcpdump, a shame because I did not need it at all but it was pulled in by the app’s dependencies).
By testing directly setfattr I found it had the same problem on all containers, as said by @stgraber
Maybe Samba could be setup in a way that don’t require this setfattr instruction. I installed my app in a Centos container with good success, but I used another tool than the standard installer, so it bypassed the tcpdump blocker and it worked fine afterward, it was not the app itself that needed it, only the installer.
EDIT
This is no longer true, rpm has been enhanced: -> bugzilla and as such it’s now possible to yum install tcpdump in an unprivileged recent (7) centos container.
No, shiftfs will not allow such additional privileged VFS operations.
shiftfs allows us to skip the costly shifting of the container filesystem and will allow us to share data between two containers that are on non-overlappin maps, but that’s about it.
