Jonathan Billings wrote:
> So, the chronyd systemd unit looks like this:
>
> # /usr/lib/systemd/system/chronyd.service
> [Unit]
> Description=NTP client/server
> Documentation=man:chronyd(8) man:chrony.conf(5)
> After=ntpdate.service sntp.service ntpd.service
> Conflicts=ntpd.service systemd-timesyncd.service
> ConditionCapability=CAP_SYS_TIME
>
> [Service]
> Type=forking
> PIDFile=/var/run/chrony/chronyd.pid
> EnvironmentFile=-/etc/sysconfig/chronyd
> ExecStart=/usr/sbin/chronyd $OPTIONS
> ExecStartPost=/usr/libexec/chrony-helper update-daemon
> PrivateTmp=yes
> ProtectHome=yes
> ProtectSystem=full
>
> [Install]
> WantedBy=multi-user.target
>
> So, you'll notice there are "ProtectHome=yes" and "ProtectSystem=yes"
> settings in the Service section. This sets up a private namespace for
> the systemd unit so /home, /root and /run/user are made inaccessible
> and empty (ProtectHome), and /usr, /boot and /etc are read-only
> (ProtectSystem). It does this to reduce the ability of a malicious
> NTP server attacking the system through bogus NTP traffic (which is a
> real thing that can happen). Many systemd services limit their
> processes this way.
>
> I suspect that is why you're seeing stale file handle errors, the
> kernel can't set up the namespace for directories that are now stale
> on the system.
>
> You can probably just do a lazy unmount (umount -l) to make them go
> away until you reboot. You can also disable the namespaced
> directories by doing a 'systemctl edit chronyd.service' and setting
> the options to 'off', but you'll be reducing the security of your
> system.
Thanks - that all makes sense - unfortunately 'umount -l' didn't work :-(
I've actually now rebooted the box - but if something like this happens again, maybe I could use a drop-in snippet in /run/systemd/system/ to turn the options off - which would then only last until the next reboot ?
Thanks
James Pearson
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
