Gionatan Danti <g.danti@xxxxxxxxxx> writes: > Il 2020-07-31 19:09 Gionatan Danti ha scritto: >> I did not know that systemd would, with specific settings, create a >> private mysql data dir. >> I would try the var_lib_t approach more widely. >> Thanks. > > Mmm, it seems labeling the link as var_lib_t is not always sufficient. > Doing a mongodb test relocation from /var/lib/mongodb to /zzz/mongodb > the service does not start, even if I can see the link having > var_lib_t label: > > # ls -alZ /var/lib/ > ... > lrwxrwxrwx. root root unconfined_u:object_r:var_lib_t:s0 mongodb > -> /zzz/mongodb > > Indeed, I can see the following in /var/log/audit: > > type=AVC msg=audit(1596222151.576:253): avc: denied { read } for > pid=4313 comm="mongod" name="mongodb" dev="dm-0" ino=33673444 > scontext=system_u:system_r:mongod_t:s0 > tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=lnk_file > permissive=0 > > Relabeling the synlink with its "native" label via restorecon -RF > produce the following: > > # ls -alZ /var/lib/ > ... > lrwxrwxrwx. root root system_u:object_r:mongod_var_lib_t:s0 > mongodb -> /zzz/mongodb > > But the service again does not start, with the followin logs: > > type=AVC msg=audit(1596222240.363:257): avc: denied { read } for > pid=4344 comm="mongod" name="mongodb" dev="dm-0" ino=33673444 > scontext=system_u:system_r:mongod_t:s0 > tcontext=system_u:object_r:mongod_var_lib_t:s0 tclass=lnk_file > permissive=0 > > What would be the best approach in this case? I know that one approach > would be to use a bind mount, but I would like to avoid it because: > a) it has bad filesystem discoverably (you had to search for bind > mount explicitly, while a symlink is visible even with a simple ls) > b) I need to setup a fcontext <<None>> for the actual dir which is > bind-mounted (otherwise, a "restorecon -RF /zzz/" will cause issues, > by relabeling any files with default_t) > > I am open to suggestions... > Thanks. Everyone who has business in /var/lib should probably be able to read var_lib_t lnk_files. You can use audit2allow to allow these entities to read symlinks of type var_lib_t Again though, there is a larger picture here and I would argue that your distribution maintainer should acknowledge that. -- gpg --locate-keys dominick.grift@xxxxxxxxxxx Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift