5/3/2023 0 Comments Batchmod permissions resetTmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) Tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) Securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered) Tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=230660k,mode=755) Udev on /dev type devtmpfs (rw,nosuid,relatime,size=1132716k,nr_inodes=283179,mode=755)ĭevpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) Proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) Sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) Ls -l output after sudo chmod a+rwx * / $ ls -lahĭrwxrwxrwx 2 root root 4096 Feb 6 20:50 binĭrwxrwxrwx 3 root root 4096 Feb 6 20:50 bootĭrwxrwxrwx 2 root root 4096 Feb 6 20:46 cdromĭrwxrwxrwx 19 root root 4240 Feb 6 20:51 devĭrwxrwxrwx 150 root root 12288 Feb 6 20:50 etcĭrwxrwxrwx 3 root root 4096 Feb 6 20:46 homeĭrwxrwxrwx 25 root root 4096 Feb 6 20:50 libĭrwxrwxrwx 2 root root 16384 Feb 6 20:44 lost+foundĭrwxrwxrwx 4 root root 4096 Feb 6 20:51 rootĭrwxrwxrwx 30 root root 960 Feb 6 20:56 runĭrwxrwxrwx 2 root root 12288 Feb 6 20:50 sbinĭrwxrwxrwx 13 root root 0 Feb 6 20:51 sysĭrwxrwxrwt 10 root root 4096 Feb 6 20:56 tmpĪfter reboot: (Just to be sure, i did a manual sync before rebooting) / $ ls -lĭrwxr-xr-x 19 root root 4240 Feb 6 20:57 devĭrwxr-xr-x 29 root root 920 Feb 6 20:57 runĭr-xr-xr-x 13 root root 0 Feb 6 20:57 sysĭrwxrwxrwt 10 root root 4096 Feb 6 20:57 tmp Lrwxrwxrwx 1 root root 29 Feb 6 20:50 vmlinuz -> / $ Ls -l output just after installation: / $ ls -l /ĭrwxr-xr-x 2 root root 4096 Feb 6 20:50 binĭrwxr-xr-x 3 root root 4096 Feb 6 20:50 bootĭrwxr-xr-x 2 root root 4096 Feb 6 20:46 cdromĭrwxr-xr-x 19 root root 4240 Feb 6 20:51 devĭrwxr-xr-x 150 root root 12288 Feb 6 20:50 etcĭrwxr-xr-x 3 root root 4096 Feb 6 20:46 home So I get the feeling some application binary is trying to be smart and "fix" the permissions for me, but which one? Unfortunately no calls got logged except for my own chmod a+rwx * test call. Hoping to get a clue where to search for, I replaced /bin/chmod with a shell script calling the "real" chmod, the shell script additionally logs the chmod call with its parameters to a file on disk. For completeness, it does reset /dev, /proc, /run and /sys. It seems Mint 17.3 also resets permissions, but not on the /srv directory. I tried to reproduce this phenomena with the slightly older Linux Mint 17.3 which I have been using for some time without problems. I checked the mount output to see if something strange was mounted, this was not the case as far as I could see (Mount output below). Mint 18 apparently uses systemd by default, I did not try to remove the systemd scripts as that would probably just break the system. I also tried removing all scripts in /etc/init.d, in the hope to pinpoint a "smart" init script, but permissions still got reset after reboot. The directories /bin, /boot, /cdrom, /etc, /lib, /lib64, /lost+found, /media, /mnt, /opt, /root, /sbin, /tmp and /usr are not affected. I can reproduce this with a fresh Linux Mint 18 installation in VirtualBox.Īfter some more testing, it seems that the permissions of /dev, /home, /proc, /run, /sys and /var are reset after reboot as well. Whenever I grant the world write access using sudo chmod a+rwx /srv then all is well, except that after a reboot, the permissions revert back to the old permissions. I have a problem that the access permissions for group and world access on the /srv directory get reverted on reboot.
0 Comments
Leave a Reply. |