Too broad permissions on new domain files

SohKa · October 29, 2024, 11:53am

I have searched the forum for similar issues

on

This category is for general issues regarding YunoHost, NOT apps.

on

This form is written in English but feel free to write in French if you’re more comfortable!

on

What type of hardware are you using

Raspberry Pi 3, 4+

What YunoHost version are you running

12.0.4.1

How are you able to access your server

The webadmin
SSH

Are you in a special context or did you perform specific tweaking on your YunoHost instance ?

Yes, installation based on RPi OS Bookworm Lite

Describe your issue

Hi,
I experience a really weird behaviour related to the file/directory permissions in my Raspberry Pi 4 Yunohost.

When I add a new domain with the admin web interface, the new related files in /etc/nginx/conf.d and /etc/dnsmasq.d have a 666 permissions mode and the new related directories have a 777 permissions mode. But when I add a domain with the command line, the files and directories have the correct permissions mode (644 for files and 755 for directories).

In the following output, brol17.eu, brol42.test, brol46.eu and brol45.test have been added with the admin web interface:

root@brol:~# ls -ltr /etc/nginx/conf.d/
total 172
-rw-r--r-- 1 root root  159 Oct 24 12:01 acme-challenge.conf.inc
-rw-r--r-- 1 root root   19 Oct 24 12:01 global.conf
-rw-r--r-- 1 root root   94 Oct 24 12:01 yunohost_http_errors.conf.inc
-rw-r--r-- 1 root root  109 Oct 24 12:01 ssowat.conf
-rw-r--r-- 1 root root  981 Oct 24 12:01 yunohost_sso.conf.inc
-rw-r--r-- 1 root root 1657 Oct 24 12:01 security.conf.inc
-rw-r--r-- 1 root root  864 Oct 24 12:01 yunohost_admin.conf
-rw-r--r-- 1 root root  823 Oct 24 12:01 yunohost_admin.conf.inc
-rw-r--r-- 1 root root 1065 Oct 24 12:01 yunohost_api.conf.inc
drwxr-xr-x 2 root root 4096 Oct 24 12:01 default.d
-rw-r--r-- 1 root root   60 Oct 24 12:04 yunohost_panel.conf.inc
drwxr-xr-x 2 root root 4096 Oct 24 12:05 brol.eu.d
-rw-r--r-- 1 root root 1575 Oct 24 12:08 brol.eu.conf
-rw-r--r-- 1 root root 1586 Oct 24 12:08 brols.eu.conf
drwxr-xr-x 2 root root 4096 Oct 24 12:08 brols.eu.d
-rw-r--r-- 1 root root 1586 Oct 24 12:11 sohka.eu.conf
drwxr-xr-x 2 root root 4096 Oct 24 12:11 sohka.eu.d
drwxr-xr-x 2 root root 4096 Oct 24 12:13 brol15.eu.d
drwxr-xr-x 2 root root 4096 Oct 24 12:18 brol1.eu.d
-rw-r--r-- 1 root root 1619 Oct 24 12:36 brol14.test.conf
drwxr-xr-x 2 root root 4096 Oct 24 12:36 brol14.test.d
-rw-r--r-- 1 root root 1619 Oct 24 12:38 brol15.test.conf
drwxr-xr-x 2 root root 4096 Oct 24 12:39 brol15.test.d
-rw-r--r-- 1 root root 1619 Oct 24 12:47 brol16.test.conf
drwxr-xr-x 2 root root 4096 Oct 24 12:47 brol16.test.d
-rw-rw-rw- 1 root root 1597 Oct 24 13:16 brol17.eu.conf
drwxrwxrwx 2 root root 4096 Oct 24 13:16 brol17.eu.d
-rw-rw-rw- 1 root root 1619 Oct 24 15:57 brol42.test.conf
drwxrwxrwx 2 root root 4096 Oct 24 15:57 brol42.test.d
-rw-r--r-- 1 root root 1619 Oct 24 16:00 brol43.test.conf
drwxr-xr-x 2 root root 4096 Oct 24 16:00 brol43.test.d
-rw-r--r-- 1 root root 1619 Oct 24 16:03 brol44.test.conf
drwxr-xr-x 2 root root 4096 Oct 24 16:03 brol44.test.d
-rw-r--r-- 1 root root 1597 Oct 24 16:25 brol45.eu.conf
drwxr-xr-x 2 root root 4096 Oct 24 16:25 brol45.eu.d
-rw-rw-rw- 1 root root 1597 Oct 24 17:52 brol46.eu.conf
drwxrwxrwx 2 root root 4096 Oct 24 17:52 brol46.eu.d
-rw-rw-rw- 1 root root 1619 Oct 25 15:18 brol45.test.conf
drwxrwxrwx 2 root root 4096 Oct 25 15:18 brol45.test.d
-rw-r--r-- 1 root root 1630 Oct 29 11:59 brol46.local.conf
drwxr-xr-x 2 root root 4096 Oct 29 11:59 brol46.local.d
-rw-r--r-- 1 root root 1630 Oct 29 12:01 brol47.local.conf
drwxr-xr-x 2 root root 4096 Oct 29 12:01 brol47.local.d

After I reboot my server, I can’t directly reproduce this issue. The files/directories generated when adding a domain via the web interface have the proper permissions mode (644 for files and 755 for directories). I must wait a few hours before the issue gets triggered again (and it remains until I reboot again). I have no idea what’s the trigger, I don’t think I do any manual action that could do this.

Can someone else can try to reproduce this issue, please? I could reproduce it on another RPi 4 server (my production one).

Share relevant logs or error messages

(no relevant logs)

Aleks · October 29, 2024, 12:48pm

Personally I’m unable to reproduce this issue, I have a 12.x server which has been up for quite some time, just created a domain and the permissions are just fine …

SohKa · October 29, 2024, 2:51pm

Here is some additional information to document the troubleshooting of this issue:

root@brol:~# grep '^UMASK' /etc/login.defs
UMASK		022
root@brol:~# umask
0022
root@brol:~# systemctl show yunohost-api | grep -i umask
UMask=0022

root@brol:~# mkdir -p /etc/nginx/conf.d/testdir
root@brol:~# ls -ld /etc/nginx/conf.d/testdir
drwxr-xr-x 2 root root 4096 Oct 29 15:27 /etc/nginx/conf.d/testdir
root@brol:~# getfacl /etc/nginx/conf.d
getfacl: Removing leading '/' from absolute path names
# file: etc/nginx/conf.d
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

root@brol:~# grep umask ~/.bashrc
# Note: PS1 and umask are already set in /etc/profile. You should not
# umask 022

root@brol:~# sudo systemd-run touch /tmp/foobar
Running as unit: run-r81ffd63ca3a74731b46c91afa6ccd40d.service
root@brol:~# ls -l /tmp/foobar
-rw-r--r-- 1 root root 0 Oct 29 15:28 /tmp/foobar
root@brol:~# systemd-run sh -c 'umask > /tmp/foobar'
Running as unit: run-r96548cff13ad4cd68c8559e209d1ded6.service
root@brol:~# cat /tmp/foobar
0022

Also, I added the domain brol52.local at 13:39 and the domain brol53.local at 15:22.

root@brol:~# ls -ltr /etc/nginx/conf.d/{brol52.local.conf,brol53.local.conf}
-rw-r--r-- 1 root root 1630 Oct 29 13:39 /etc/nginx/conf.d/brol52.local.conf
-rw-rw-rw- 1 root root 1630 Oct 29 15:22 /etc/nginx/conf.d/brol53.local.conf

First one has correct permissions, second one has wrong permissions. So between 13:39 and 15:22, something must have triggered the issue. But as you can see, there is nothing relevant in the logs.

root@brol:~# grep -ir 'cron' /var/log/cron.log | grep '^2024-10-29T13:\|^2024-10-29T14:\|^2024-10-29T15:'
2024-10-29T13:17:01.751327+01:00 brol CRON[14631]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
2024-10-29T14:17:01.824899+01:00 brol CRON[16725]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
2024-10-29T15:17:01.901739+01:00 brol CRON[16765]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)

root@brol:~# ls -la /etc/cron.hourly/
total 16
drwxr-xr-x   2 root root 4096 Jul  4 02:06 .
drwxr-xr-x 108 root root 4096 Oct 24 12:05 ..
-rwxr-xr-x   1 root root  191 Feb 22  2012 fake-hwclock
-rw-r--r--   1 root root  102 Mar  2  2023 .placeholder

root@brol:~# cat /etc/cron.hourly/fake-hwclock
#!/bin/sh
#
# Simple cron script - save the current clock periodically in case of
# a power failure or other crash

if (command -v fake-hwclock >/dev/null 2>&1) ; then
  fake-hwclock save
fi

root@brol:~# systemctl list-timers --all
NEXT                        LEFT        LAST                        PASSED       UNIT                         ACTIVATES                     
Wed 2024-10-30 00:00:00 CET 8h left     Tue 2024-10-29 11:00:14 CET 4h 44min ago dpkg-db-backup.timer         dpkg-db-backup.service
Wed 2024-10-30 00:00:00 CET 8h left     Tue 2024-10-29 11:00:14 CET 4h 44min ago logrotate.timer              logrotate.service
Wed 2024-10-30 03:30:56 CET 11h left    Tue 2024-10-29 11:25:09 CET 4h 19min ago man-db.timer                 man-db.service
Wed 2024-10-30 05:01:21 CET 13h left    Tue 2024-10-29 12:32:35 CET 3h 12min ago apt-daily.timer              apt-daily.service
Wed 2024-10-30 06:08:37 CET 14h left    Tue 2024-10-29 11:10:32 CET 4h 34min ago apt-daily-upgrade.timer      apt-daily-upgrade.service
Wed 2024-10-30 06:25:00 CET 14h left    Tue 2024-10-29 11:00:14 CET 4h 44min ago ntpsec-rotate-stats.timer    ntpsec-rotate-stats.service
Wed 2024-10-30 11:15:12 CET 19h left    Tue 2024-10-29 11:15:12 CET 4h 29min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Sun 2024-11-03 03:10:04 CET 4 days left Tue 2024-10-29 11:01:21 CET 4h 43min ago e2scrub_all.timer            e2scrub_all.service
Mon 2024-11-04 01:34:10 CET 5 days left Tue 2024-10-29 12:27:32 CET 3h 17min ago fstrim.timer                 fstrim.service

9 timers listed.

root@brol:~# journalctl --since "2024-10-29 13:38:00" --until "2024-10-29 15:23:00" -u dpkg-db-backup.timer
-- No entries --
root@brol:~# journalctl --since "2024-10-29 13:38:00" --until "2024-10-29 15:23:00" -u logrotate.timer
-- No entries --
root@brol:~# journalctl --since "2024-10-29 13:38:00" --until "2024-10-29 15:23:00" -u man-db.timer
-- No entries --
root@brol:~# journalctl --since "2024-10-29 13:38:00" --until "2024-10-29 15:23:00" -u apt-daily.timer
-- No entries --
root@brol:~# journalctl --since "2024-10-29 13:38:00" --until "2024-10-29 15:23:00" -u apt-daily-upgrade.timer
-- No entries --
root@brol:~# journalctl --since "2024-10-29 13:38:00" --until "2024-10-29 15:23:00" -u ntpsec-rotate-stats.timer
-- No entries --
root@brol:~# journalctl --since "2024-10-29 13:38:00" --until "2024-10-29 15:23:00" -u systemd-tmpfiles-clean.timer
-- No entries --
root@brol:~# journalctl --since "2024-10-29 13:38:00" --until "2024-10-29 15:23:00" -u e2scrub_all.timer
-- No entries --
root@brol:~# journalctl --since "2024-10-29 13:38:00" --until "2024-10-29 15:23:00" -u fstrim.timer
-- No entries --

root@brol:~# cat /etc/cron.d/*
30 3 * * 0 root test -e /run/systemd/system || SERVICE_MODE=1 /usr/lib/aarch64-linux-gnu/e2fsprogs/e2scrub_all_cron
10 3 * * * root test -e /run/systemd/system || SERVICE_MODE=1 /sbin/e2scrub_all -A -r
25 6     * * * root if [ ! -d /run/systemd/system ] && [ -x /usr/libexec/ntpsec/rotate-stats ] ; then /usr/libexec/ntpsec/rotate-stats ; fi
SHELL=/bin/bash
0 7,19 * * * root : YunoHost Automatic Diagnosis; sleep $((RANDOM\%1200)); yunohost diagnosis run --email > /dev/null 2>/dev/null || echo "Running the automatic diagnosis failed miserably"

root@brol:~# ls -la /etc/cron.d
total 24
drwxr-xr-x   2 root root 4096 Oct 24 12:04 .
drwxr-xr-x 108 root root 4096 Oct 24 12:05 ..
-rw-r--r--   1 root root  202 Mar  5  2023 e2scrub_all
-rw-r--r--   1 root root  140 Jan 17  2023 ntpsec
-rw-r--r--   1 root root  102 Mar  2  2023 .placeholder
-rw-r--r--   1 root root  205 Oct 24 12:04 yunohost-diagnosis

SohKa · October 29, 2024, 2:53pm

Thank you for trying, Aleks! I also noticed this issue on my production server when it was still in version 11.x (latest one).

SohKa · October 30, 2024, 9:42am

I’ve started over my test setup to make sure nothing is interfering.

Here are my steps:

Write RPi OS Bookworm Lite (64bits) on new micro sd card with RPi official Imager with custom parameters (user id different than YNH admin one, SSH public key, QWERTY US keyboard and Europe/Brussels timezone
Plug SD card on RPi and power it on
Connect via SSH with temporary user
Base setup:

sudo apt update
sudo apt full-upgrade
sudo raspi-config

Via ‘5 Localisation Options’ > ‘Locale’, select following locales: en_GB.UTF-8, en_US.UTF-8, fr_BE.UTF-8 and nl_BE.UTF-8
Via ‘Advanced Options’ > ‘Bootloader Version’, select ‘Default’ bootloader version (also called critical, meaning stable)
Select ‘yes’ when it ask to restore boot ROM to defaults
Then in the raspi-config menu, select ‘Finish’ and then confirm you want to reboot
Connect back via SSH when RPi is back online
Install YNH testing:

sudo -i
curl https://install.yunohost.org/bookworm | bash -s -- -d testing
yunohost tools postinstall

Reboot again

sudo reboot

For future SSH connections, use new Ynh admin user

Also for the reference, here is the RPi firmware version:

BOOTLOADER: up to date
   CURRENT: Mon Apr 15 01:12:14 PM UTC 2024 (1713186734)
    LATEST: Mon Apr 15 01:12:14 PM UTC 2024 (1713186734)
   RELEASE: default (/lib/firmware/raspberrypi/bootloader-2711/default)
            Use raspi-config to change the release.

  VL805_FW: Dedicated VL805 EEPROM
     VL805: up to date
   CURRENT: 000138c0
    LATEST: 000138c0

Now I’ll wait and see if the issue is triggered again.