I have directory permission warning for /etc/bluetooth/ for a while. Changed permissions for filestystem to the one from package.
Is that something to report also?
[2023-12-22T05:29:33+0100] [ALPM] warning: directory permissions differ on /etc/bluetooth/
filesystem: 755 package: 555
Well, that folder is mostly only part of these packages:
pacman -Qo /etc/bluetooth/
/etc/bluetooth/ is owned by bluez 5.71-2
/etc/bluetooth/ is owned by bluez-utils-compat 5.66-2
check the history of each PKGBUILD file and you may find out if it got changed by Arch or from the upstream project.
The package’s permissions are wrong. 555 makes no sense on a root-owned directory, because root has write access to everything anyway. 755 is the correct value.
Permissions 555 are right here as that is wanted by the upstream project for the service file. Please read code before bubbling something random! Also has been that way since a year now: fix configuration dirextory permission - the bluetooth.service wants now... (016f58e6) · Commits · Arch Linux / Packaging / Packages / bluez · GitLab
Thanks a lot @Aragorn for the clarification. 
I changed the permissions back to what it actually was: 755
fix configuration dirextory permission - the bluetooth.service wants now ConfigurationDirectoryMode=0555
PKGBUILD
# ship upstream main config file
install -dm555 "${pkgdir}"/etc/bluetooth
Are you saying there is a configuration mistake upstream?
@philm Yeah, I also think Arch would not make such a mistake.
well, change it to 555 as bluetooth.service wants now ConfigurationDirectoryMode=0555. Without that change your Bluetooth devices won’t work properly. @Aragorn, please give that info to the moderators and tell users to fix folder permissions to 555 on Bluetooth issues. thx.
With all due respect, @philm — which appears to be more than how you’re addressing me here — anyone who understands UNIX knows that the root account (and any process with root privileges) always has write access to everything, as long as the filesystem it’s on is mounted read/write.
755 permissions means -rwxr-xr-x, or in the event of a directory, drwxr-xr-x.555 permissions means -r-xr-xr-x, or in the event of a directory, dr-xr-xr-x.In other words, 555 means that the owner of the directory does not have write permission, but considering that /etc/bluetooth is owned by the root account, removing the write permission for the owner — i.e. the root account — is futile.
Try it. Create some root-owned directory or root-owned file in /tmp somewhere. Call it test and give it 555 permissions. Or 444 permissions, if you like. Make sure the root account does not have write permission. You can even remove the write permission for the root user on the parent directory of test.
And now, as root, try deleting the file. Poof! It’s gone, even though all write permission for the root account had been revoked. Tada! How is this possible? It’s because the root account bypasses all write permission restrictions — provided that the filesystem is read/write-mounted and that the file or directory does not have the immutable flag set (chattr +i). It is defined that way in the kernel.
[nx-74205:/dev/pts/3][/home/aragorn]
[aragorn] > su -
Password:
[nx-74205:/dev/pts/3][/root] # cd /tmp
[nx-74205:/dev/pts/3][/tmp] # mkdir test.d
[nx-74205:/dev/pts/3][/tmp] # mkdir test.d/foo
[nx-74205:/dev/pts/3][/tmp] # touch test.d/foo/bar.txt
[nx-74205:/dev/pts/3][/tmp] # tree -p test.d
[drwxr-xr-x] test.d
└── [drwxr-xr-x] foo
└── [-rw-r--r--] bar.txt
2 directories, 1 file
[nx-74205:/dev/pts/3][/tmp] # chmod -R 555 test.d
[nx-74205:/dev/pts/3][/tmp] # tree -p test.d
[dr-xr-xr-x] test.d
└── [dr-xr-xr-x] foo
└── [-r-xr-xr-x] bar.txt
2 directories, 1 file
[nx-74205:/dev/pts/3][/tmp] # rm -f test.d/foo/bar.txt
[nx-74205:/dev/pts/3][/tmp] # tree -p test.d/
[dr-xr-xr-x] test.d/
└── [dr-xr-xr-x] foo
2 directories, 0 files
[nx-74205:/dev/pts/3][/tmp] # rm -rf test.d/foo
[nx-74205:/dev/pts/3][/tmp] # tree -p test.d/
[dr-xr-xr-x] test.d/
0 directories, 0 files
[nx-74205:/dev/pts/3][/tmp] # rm -rf test.d/
[nx-74205:/dev/pts/3][/tmp] # ls -l test.d
ls: cannot access 'test.d': No such file or directory
[nx-74205:/dev/pts/3][/tmp] #
So if the packager upstream says that it should be 555, then it’s probably because that packager has never heard of UNIX and grew up on Microsoft Windows, as — pardon me for saying this — most of you did.
Perhaps both you and the packager should read my tutorial on UNIX permissions. I wrote that for a reason, and everything in it is 100% correct.
Now if you’ll excuse me, I think I have some “random bubbling” to do. 
Oh yes, they would. Most of today’s GNU/Linux developers have never seen a (proprietary) UNIX system from up close. They all grew up on Microsoft Windows, and then they heard of this thing called “(GNU/)Linux”, and they decided to install it, and later, to write code for it.
This is just as true for Arch and Gentoo as for most other distributions, with the possible exception of Slackware and Devuan, because those guys are quite conservative when it comes to GNU/Linux, and they want to stay as close to the original UNIX as possible. Most of them do indeed have UNIX experience — as do I. (I guess that shows how old I am.)
@Philm did not set the file permissions to 555. The bluez developers set it that way. Manjaro is just using their app the way they configured it.
I know that, @ben75, but @philm is the one chastising me — and for that matter, quite condescendingly — for pointing out that the packager has their facts wrong, and he appears to have full confidence in the packager’s erroneous judgment without understanding why the packager is wrong.
Now, if /etc/bluetooth were owned by another system user than root, 555 permissions could possibly make sense — I don’t really know why it should not have write permission for the owner, but okay — but not so if the directory and its contents are owned by root. Anyone who properly understands UNIX/POSIX knows this.
Taking away root’s write permission on any file or directory has no effect whatsoever on root’s ability to write to the file or directory, because on a UNIX system — any UNIX system — root is God and has write access to everything, as long as the filesystem it’s on is mounted read/write — as I’ve demonstrated above.
Its probably related to some possibility where the owner is not root.
As you said, when owned by root it doesnt matter … if it happened to be owned by another user, maybe through some security problems of bluetooth… because we are talking about bluetooth … then it ensures that other non-root owner does not have write access.
Also note its not exactly new, and more than just bluetooth is involved … systemd and bluez interact with these configured assumptions as well. ex
https://bbs.archlinux.org/viewtopic.php?id=280175
Well, setting other file permissions can lead to this:
> systemctl status bluetooth.service
...
systemd[1291]: ConfigurationDirectory 'bluetooth' already exists but the mode is different. (File system: 755 ConfigurationDirectoryMode: 555)
...
> sudo journalctl -eu bluetooth
Oct 04 11:35:26 HOST systemd[1]: Bluetooth service was skipped because of a failed condition check (ConditionPathIsDirectory=/sys/class/bluetooth).
Oct 04 11:35:27 HOST systemd[1]: Starting Bluetooth service...
Oct 04 11:35:27 HOST systemd[895]: ConfigurationDirectory 'bluetooth' already exists but the mode is different. (File system: 755 ConfigurationDirectoryMode: 555)
Oct 04 11:35:27 HOST bluetoothd[895]: Bluetooth daemon 5.65
Oct 04 11:35:27 HOST systemd[1]: Started Bluetooth service.
Oct 04 11:35:27 HOST bluetoothd[895]: Starting SDP server
Oct 04 11:35:27 HOST bluetoothd[895]: Bluetooth management interface 1.22 initialized
Modifying systemd’s bluetooth.service unit, i.e. changing the ConfigurationDirectoryMode value from 0555 to 0755, reconciles the /etc/bluetooth directory created by bluez with mode 0755 with the service unit’s key-value setting of 0555. Warnings disappears after the service gets reloaded. However upstream seems to had a reason to have 555 here …
Similar issues:
Most issues with bluetooth are due to the “wrong” set folder permissions!
Debian for example has this folder with 755, which leads to errors. Also Ubuntu, Fedora and others also have 755 here. Most likely systemd is not forcing the permissions internally as intended. Arch “solves” it by also setting the folder to 555 as they ship config files with the package.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017988
Projects like open embedded even patch it
https://lists.openembedded.org/g/openembedded-core/message/171494
So to summarize, the real problem is that the bluetooth service is wrongly enforcing those directory permissions (and totally unnecessary) resulting in service errors. So until the developers (if ever) revert that we’re forced to set directory permissions to 555.
Either that or setting ConfigurationDirectoryMode to 0755 in the bluetooth.service (under “/lib/systemd/system/bluetooth.service”).
Thanks to all for your contribution to shedding some light on this. It helps understanding more of it.
I mark @philm answer as the solution here. Feel free to object if you disagree.
Thanks.
This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.