Re: [systemd-devel] systemd and chroot()
On 6/4/19 1:14 PM, Zbigniew Jędrzejewski-Szmek wrote:
> 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?
The patch set is basically adding a pseudo to all the export
which should make things a bit more container friendly...
There is the thread
https://www.spinics.net/lists/linux-nfs/msg73006.html
steved.
>
> 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.0 -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@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and chroot()
On 6/4/19 12:45 PM, Matthew Garrett wrote:
> On Tue, Jun 4, 2019 at 9:42 AM Steve Dickson wrote:
>> 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
>
> This is an SELinux policy violation, nothing to do with systemd.
Yeah... that's what I originally thought it was but when
it was suggested to set AmbientCapabilities=CAP_SYS_CHROOT
in the service unit I figured I would run it by you guys..
> You're probably not seeing it when you run the daemon by hand because
> the SELinux policy doesn't specify a transition in that case, so the
> daemon doesn't end up running in the confined context.
>
Makes sense... thanks!
steved.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and chroot()
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.0 -0400
> +++ nfs-mountd.service2019-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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and chroot()
On Tue, Jun 4, 2019 at 9:42 AM Steve Dickson wrote:
> 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
This is an SELinux policy violation, nothing to do with systemd.
You're probably not seeing it when you run the daemon by hand because
the SELinux policy doesn't specify a transition in that case, so the
daemon doesn't end up running in the confined context.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd and chroot()
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
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.0 -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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
