ls -al /boot
total 380088
drwx------ 5 root root 4096 Jan 1 1970 .
drwxr-xr-x 1 root root 216 Nov 26 02:02 ..
drwx------ 5 root root 4096 Dec 4 01:41 EFI
-rwx------ 1 root root 218054894 Dec 19 10:35 initramfs-5.15-x86_64-fallback.img
-rwx------ 1 root root 154649022 Dec 19 10:35 initramfs-5.15-x86_64.img
-rwx------ 1 root root 5678080 Nov 8 21:02 intel-ucode.img
-rwx------ 1 root root 22 Dec 14 15:18 linux515-x86_64.kver
drwx------ 3 root root 4096 Dec 19 10:42 loader
drwx------ 2 root root 4096 Nov 27 03:45 memtest86+
-rwx------ 1 root root 10793088 Dec 19 10:35 vmlinuz-5.15-x86_64
tried chmod -R 755 /boot as root, unmonting and do the command on /boot the remounting gives and /boot with 755 permission, but don’t persist after a reboot. so since 700 permission on /boot doesn’t look bad for me, and those warnings can be ignored, my question is are there any guidelines for permission for / and it subsidiaries, especially /home. thanks alot.
For the default permissions of /boot i suggest you to look at your /etc/fstab where it is mounted by default at boot most likely.
It most likely has an umask= option that force it…
Posting the contents of that file within block-code tags as usual would help
PS: Warnings normally won’t hurt but it sure is irritating…
The additional permissions on /boot don’t really matter, unless you want to view its contents as a non-root user, in which case 700 is too restrictive. 755 is a sane value.
Two things here…
The -R option is wrong, because you don’t want the permissions changed recursively and indiscriminately. Besides, the contents of /boot are never read by anything while the system is running, because /boot is only ever read and possibly written to by the boot loader, which runs with (a kind of) root privileges — actually, at that point of the boot process, there is no distinction yet between root and non-root, because the kernel hasn’t even been loaded yet.
The only time the permissions on /boot — which is itself a directory entry in the root directory — do not survive a reboot is if your root filesystem is mounted read-only, which should never happen by default, but which can happen if the filesystem was uncleanly shut down and has errors. You should therefore fix those errors with fsck from a live USB/CD/DVD session.
The first-level directories in the root directory should all be owned root:root and have 755 permissions, except for…
/tmp, which should have 1777 permissions, i.e. drwxrwxrwt; and…
/root, which in Manjaro is set up with 750 permissions but which should best be given 700 permissions.
Your home directory is your own domain, and you can do with that as you please, albeit that this may cause problems with regard to your desktop environment and applications. Your home directory itself can have 700 permissions if you feel this is more secure.
But when changing permissions, do bear in mind that -R means “recursive”. You do not want to give execute permission on every file in your home directory.
Only sideways related, I’ve written the following elaborate tutorial on permissions, and I recommend that you’d read it.
/boot would normally have a Linux-native filesystem on it, in which case the permissions are stored in the individual inodes of the files and directories. It is only necessary to specify permissions at mount time — and thus in /etc/fstab — for non-POSIX filesystems such as vfat and ntfs.
Of course, if the OP is using the EFI partition as /boot — some boot loaders require this — then the permissions on its contents must indeed be set at mount time.
But even then still, changing the permissions on the /boot directory itself should survive a reboot, and OP claims they do not, which leads me to believe that OP’s root filesystem is mounted read-only, and if that is the case, then the filesystem is most likely damaged — the kernel will automatically remount a damaged ext3/ext4 filesystem as read-only.
@Aragorn the OP was talking about permissions for “group” and “other” that are eliminated, that is something different as read-only
The OP also mentioned that the permissions didn’t survive a reboot even-though they were manually set at run-time , hence why it is (IMHO) related to mount options umask used at boot time
I personally prefer to use umask=0007,gid=sudo
edit: The above gives access to the main user without root’ing, but prevents it at same time for other users, because the main user is by default member of the sudo group…
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=55AA-B60D /boot vfat umask=0077 0 2
UUID=62fa3c67-883a-4cc0-828a-fd366728813e / btrfs subvol=/@,defaults,noatime,discard=async,compress=no,space_cache=v2,max_inline=256,commit=120 0 0
UUID=62fa3c67-883a-4cc0-828a-fd366728813e /var/cache btrfs subvol=/@cache,defaults,noatime,discard=async,compress=no,space_cache=v2,max_inline=256,commit=120 0 0
UUID=62fa3c67-883a-4cc0-828a-fd366728813e /var/log btrfs subvol=/@log,defaults,noatime,discard=async,compress=no,space_cache=v2,max_inline=256,commit=120 0 0
UUID=fd4fad24-0f44-4554-839a-aefb8ace7574 /home btrfs defaults,noatime,discard=async,compress=no,space_cache=v2,max_inline=256,commit=120 0 0
umask=0077 is not clear for me since chmod use (different?) numerical order, can you refer me to umask permission manual or any similar thing. thanks for the response.
The only time the permissions on /boot — which is itself a directory entry in the root directory — do not survive a reboot is if your root filesystem is mounted read-only, which should never happen by default, but which can happen if the filesystem was uncleanly shut down and has errors. You should therefore fix those errors with fsck from a live USB/CD/DVD session.
in the /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=55AA-B60D /boot vfat umask=0077 0 2
so the fsck is already enabled, no issues here, an /boot on a vfat, which has broken on me before so I always keep fsck on /boot to avoid such things, but I wonder why or how the /usr/share/polkit-1/rules.d/ changed/have been changed from the global Filesystem permission, to what is now? can packages change permission without asking or notifying user beforehand.
thanks for the response.
I’m not sure, but in theory, I think that it can indeed happen, under certain circumstances — Arch-style packages are compressed .tar archives, which do store permission information — albeit that for most part, the filesystem package is what sets the permissions.
But bear in mind that you are on the Unstable branch, and it is called that for a reason.
Note however when using my umask=0007,gid=sudo, you probably need to change 2 files, else your kernel install will barf and error-out… (I’m on Kubuntu at moment which needed it, so no idea if it is the same on Manjaro)
These patches are best applied by copying the originals into /etc/kernel/install.d first, so the modified versions will override the originals at call-time…
I see Owner:Root, Permissions:644 (Am I right?) for both kernel image and init, interesting indeed. I’ll see if I should change mounting permissions for / and /boot specifically to 700 just for uniformity. thanks for the insight.
I was looking for the equivalent of 755 in umask as not to lock necessary permission from showing correctly for booting processes, also -m is for umask correct?
