1. Forum
  2. Usenet
  3. LINUX.DEBIAN.USER

  • SystemD ProtectSystem=full still can write File in /etc outside of Work

    From Philipp Ewald@21:1/5 to All on Wed Jun 25 12:00:01 2025
    Hello,

    is it normal that a Service started with systemd still can write files ouitside it working dir?

    The prozess itsselft has it own "cd", does this break the Security setting is systemd?

    ProtectSystem=full should be read-only /etc
    what is the point of this settig if the process still can write there?


    kind regards
    --
    Philipp Ewald
    Administrator

    DigiOnline GmbH, Probsteigasse 15 - 19, 50670 Köln
    Fax: +49 221 6500-690, E-Mail: philipp.ewald@digionline.de

    AG Köln HRB 27711, St.-Nr. 5215 5811 0640
    Geschäftsführer: Werner Grafenhain

    Informationen zum Datenschutz: www.digionline.de/ds

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andy Smith@21:1/5 to Philipp Ewald on Wed Jun 25 13:40:02 2025
    Hi,

    On Wed, Jun 25, 2025 at 11:33:02AM +0200, Philipp Ewald wrote:
    ProtectSystem=full should be read-only /etc
    what is the point of this settig if the process still can write there?

    The "full" setting is indeed meant to keep the whole filesystem
    read-only for that service, except /dev, /proc, and /sys, so if yours
    isn't then there is something else going on.

    It doesn't work for user services (i.e. services started with --user
    option).

    It doesn't work if your kernel doesn't support filesystem namespaces,
    which can happen if you have systemd running inside some other
    container.

    ReadWritePaths= can be used to add paths that can be written to, so
    check there isn't one of those.

    Otherwise there is some other issue, or a bug.

    Thanks,
    Andy

    --
    https://bitfolk.com/ -- No-nonsense VPS hosting

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Wooledge@21:1/5 to Philipp Ewald on Wed Jun 25 13:40:02 2025
    On Wed, Jun 25, 2025 at 11:33:02 +0200, Philipp Ewald wrote:
    is it normal that a Service started with systemd still can write files ouitside it working dir?

    Depends on the settings in the unit file. Write restrictions are not
    the default, but there are settings you can use which will cause write restrictions to take effect.

    In systemd.exec(5):

    RootDirectory= (does a chroot)

    ProtectHome= (makes /home, /root and /run/user inaccessible)

    ProtectSystem=strict (makes most directories read-only)

    RuntimeDirectory= and friends (adds transient exceptions to
    ProtectSystem=strict)

    ReadWritePaths= (adds nontransient exceptions to ProtectSystem=strict)

    etc.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Philipp Ewald@21:1/5 to Andy Smith on Wed Jun 25 14:50:01 2025
    Hello,

    ooh man i got confused because i had also troube with logrotate service. There was Protectsystem=full not in the openvpn@service

    systemctl cat openvpn@<conf>
    # [Service]
    # Type=notify
    # PrivateTmp=true
    # WorkingDirectory=/etc/openvpn
    # ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status /run/openvpn/%i.status 10 --cd /etc/openvpn --config /etc/openvpn/%i.conf --writepid /run/openvpn/%i.pid
    # PIDFile=/run/openvpn/%i.pid
    [..]
    # DeviceAllow=/dev/null rw
    # DeviceAllow=/dev/net/tun rw
    # ProtectSystem=true
    # ProtectHome=true

    so no outbreak.... :facepalm:

    Kind regards


    On 25.06.25 13:15, Andy Smith wrote:
    Hi,

    On Wed, Jun 25, 2025 at 11:33:02AM +0200, Philipp Ewald wrote:
    ProtectSystem=full should be read-only /etc
    what is the point of this settig if the process still can write there?

    The "full" setting is indeed meant to keep the whole filesystem
    read-only for that service, except /dev, /proc, and /sys, so if yours
    isn't then there is something else going on.

    It doesn't work for user services (i.e. services started with --user
    option).

    It doesn't work if your kernel doesn't support filesystem namespaces,
    which can happen if you have systemd running inside some other
    container.

    ReadWritePaths= can be used to add paths that can be written to, so
    check there isn't one of those.

    Otherwise there is some other issue, or a bug.

    Thanks,
    Andy


    --
    Philipp Ewald
    Administrator

    DigiOnline GmbH, Probsteigasse 15 - 19, 50670 Köln
    Fax: +49 221 6500-690, E-Mail: philipp.ewald@digionline.de

    AG Köln HRB 27711, St.-Nr. 5215 5811 0640
    Geschäftsführer: Werner Grafenhain

    Informationen zum Datenschutz: www.digionline.de/ds

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andy Smith@21:1/5 to Philipp Ewald on Wed Jun 25 15:40:01 2025
    Hi,

    On Wed, Jun 25, 2025 at 02:29:05PM +0200, Philipp Ewald wrote:
    systemctl cat openvpn@<conf>
    # [Service]
    # Type=notify
    # PrivateTmp=true
    # WorkingDirectory=/etc/openvpn
    # ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status /run/openvpn/%i.status 10 --cd /etc/openvpn --config /etc/openvpn/%i.conf --writepid /run/openvpn/%i.pid
    # PIDFile=/run/openvpn/%i.pid
    [..]
    # DeviceAllow=/dev/null rw
    # DeviceAllow=/dev/net/tun rw
    # ProtectSystem=true
    # ProtectHome=true

    So in case the issue here isn't obvious for any other readers, "ProtectSystem=true" only makes /usr, /boot and /efi read-only. "ProtectSystem=full" adds /etc to that list. "Protectsystem=strict"
    makes everything EXCEPT /dev, /proc and /sys read-only.

    This is documented in "man systemd.exec".

    Thanks,
    Andy

    --
    https://bitfolk.com/ -- No-nonsense VPS hosting

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)