On Tue, Jun 04, 2019 at 12:42:35PM -0400, Steve Dickson wrote: > Hello, > > We are adding some new functionality to the NFS server that > will make it a bit more container friendly... > > This new functionality needs to do a chroot(2) system call. > This systemcall is failing with EPERM due to the > following AVC error: > > AVC avc: denied { sys_chroot } for pid=2919 comm="rpc.mountd" capability=18 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:system_r:nfsd_t:s0 tclass=capability permissive=0 It doesn't sound right to do any kind of chrooting yourself. Why can't you use the systemd builtins for this? Zbyszek > The entery in the /var/loc/audit.log > type=AVC msg=audit(1559659652.217:250): avc: denied { sys_chroot } for pid=2412 comm="rpc.mountd" capability=18 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:system_r:nfsd_t:s0 tclass=capability permissive=0 > > It definitely is something with systemd, since I can > start the daemon by hand... > > It was suggested I make the following change to the service unit > # diff -u nfs-mountd.service.orig nfs-mountd.service > --- nfs-mountd.service.orig 2019-06-04 10:38:57.000000000 -0400 > +++ nfs-mountd.service 2019-06-04 12:29:34.339621802 -0400 > @@ -11,3 +11,4 @@ > [Service] > Type=forking > ExecStart=/usr/sbin/rpc.mountd > +AmbientCapabilities=CAP_SYS_CHROOT > > which did not work. > > Any ideas on how to tell systemd its ok for a daemon > to do a chroot(2) system call? > > tia, > > steved. > _______________________________________________ > systemd-devel mailing list > systemd-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/systemd-devel _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel