File permissions of /etc/bluetooth

Support Software & Applications
7

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.

:eyes: :point_down:

[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. :point_down:

Now if you’ll excuse me, I think I have some “random bubbling” to do. :roll_eyes:

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.)

8 Likes