/dev Permissions for disks seems all wrong

dreamer3 · 2020-01-12 13:39:18

I just noticed this, but it seems all wrong. My regular user (no sudo) can repartition the drive, mkswap on any drive, etc... from my prior Linux experience that sounds WAY off... I'd expect the permissions on those devices to be 0600 or 0660 or something. But instead:

brw-rw-rw- 1 root disk 8, 0 Jan 12 08:50 /dev/sda
brw-rw-rw- 1 root disk 8, 1 Jan 12 08:50 /dev/sda1
brw-rw-rw- 1 root disk 8, 2 Jan 12 08:50 /dev/sda2
brw-rw-rw- 1 root disk 8, 3 Jan 12 08:50 /dev/sda3
brw-rw-rw- 1 root disk 8, 4 Jan 12 08:50 /dev/sda4
brw-rw-rw- 1 root disk 8, 5 Jan 12 08:50 /dev/sda5
brw-rw-rw- 1 root disk 8, 6 Jan 12 08:50 /dev/sda6
brw-rw-rw- 1 root disk 8, 7 Jan 12 08:50 /dev/sda7
brw-rw-rw- 1 root disk 8, 8 Jan 12 08:50 /dev/sda8

The whole file system is mounted 755, not sure if that is relevant.

dev on /dev type devtmpfs (rw,nosuid,relatime,size=1446212k,nr_inodes=361553,mode=755)

This is the kind of thing I thought perhaps `udev` should be handling but I didn't see any default rules that would do that at a quick glance.

I have no idea where to look next or how to fix since the dev filesystem is temporary and created at boot time.

Can anyone help?

Trilby · 2020-01-12 13:57:44

Why is /dev/ its own filesystem? Where is that from? How did you set that up?

Which instructions did you follow when you installed the OS?

dreamer3 · 2020-01-12 13:59:20

It's been a while, but the official guide:

https://wiki.archlinux.org/index.php/Installation_guide

Should it not be? It's not in `fstab` or anything... I assumed the early boot process wanted /dev to be a devtmpfs and just made that happen... is that not normal?

Trilby · 2020-01-12 14:02:29

It should be devtmpfs, but thats not what you are showing. Perhaps that is a red herring, but I'm not sure why it'd be just 'dev' in the first column.

Last edited by Trilby (2020-01-12 14:03:29)

dreamer3 · 2020-01-12 14:03:58

Looks like devtmpfs to me. The first column doesn't really mean anything for virtual file systems IIRC.

Can you confirm my permissions are weird and that they should NOT be as they are for the sda block devices?

Last edited by dreamer3 (2020-01-12 14:05:36)

frostschutz · 2020-01-12 14:10:38

Yes, it shouldn't be like that. World-readwriteable blockdevices undermine the entire permission system...

Do you have any custom udev rules that might be messing with your device nodes here?

dreamer3 · 2020-01-12 14:15:13

Nothing craazy unless I'm completely misunderstanding how the rules work:

$ cat /etc/udev/rules.d/*
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="[redacted]", NAME="wlan0"
# set scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]*|nvme[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"
# set scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"
# Samsung SyncMaster 757NF
ATTR{idVendor}="419", ATTR{idProduct}="8002", MODE="0666"
# Apple Studio Display 15"
ATTR{idVendor}="5ac", ATTR{idProduct}="9215", MODE="0666"
# Apple Studio Display 17"
ATTR{idVendor}="5ac", ATTR{idProduct}="9217", MODE="0666"
# Apple Cinema Display 23" (old)
ATTR{idVendor}="5ac", ATTR{idProduct}="9218", MODE="0666"
# Apple Cinema Display 20" (old)
ATTR{idVendor}="5ac", ATTR{idProduct}="9219", MODE="0666"
# Apple Cinema Display 24"
ATTR{idVendor}="5ac", ATTR{idProduct}="921e", MODE="0666"
# Apple Cinema HD Display 27"
ATTR{idVendor}="5ac", ATTR{idProduct}="9226", MODE="0666"
# Apple Cinema HD Display 27"
ATTR{idVendor}="5ac", ATTR{idProduct}="9227", MODE="0666"
# Apple Cinema HD Display 30"
ATTR{idVendor}="5ac", ATTR{idProduct}="9232", MODE="0666"
# Apple LED Cinema Display 24"
ATTR{idVendor}="5ac", ATTR{idProduct}="9236", MODE="0666"

dreamer3 · 2020-01-12 14:22:22

Is there supposed to be a rule somewhere in

/usr/lib/udev/rules.d/

that I can see to do this or is it "built-in" behavior?

frostschutz · 2020-01-12 14:23:42

can't test it right now but I guess you want to change some of those = to ==

man udev

       A rule consists of a comma-separated list of one or more key-value pairs. Each key has a distinct operation, depending on the used operator. Valid operators are:

       "=="
           Compare for equality.

       "!="
           Compare for inequality.

       "="
           Assign a value to a key. Keys that represent a list are reset and only this single value is assigned.

So your rules may be trying to assign attributes (=) instead of matching them (==) and the only assignment that works is the mode (0666) and it applies to everything

I'm also unfamiliar with Apple ... where did you find those rules from? If it's in the wiki somewhere it should be fixed there too.

Last edited by frostschutz (2020-01-12 14:26:04)

dreamer3 · 2020-01-12 14:26:24

Oh yikes. I don't even know where that file came from though I do have an Apple display (but not a Samsung)... but that makes sense... if the rules were NOPs and just applying the MODE = 0666 to everything.

Is there any way to "Reset" it and reapply all the rules without a reboot?

2ManyDogs · 2020-01-12 14:29:07

https://wiki.archlinux.org/index.php/Ud … _new_rules

dreamer3 · 2020-01-12 14:29:50

Yeah, I already tried that... but I presume that's not doing a RESET - that's just reapplying... which wouldn't fix the problem.

dreamer3 · 2020-01-12 14:36:14

https://github.com/jenrik/acdcontrol/co … b6741b7965

Source of the problem, and it was fixed some time ago. Kind of scary it's that easy to totally destroy your permissions.

frost: Thanks SO much for the quick help. I'm assuming after a reboot all will be well now - and we tracked down the source to make sure no one else gets bitten, so I think we're good!

frostschutz · 2020-01-12 14:38:02

It's not possible to revoke permissions (like if there is a process with an already open filehandle, it'll keep that even after chmod);

and if this is a shared hosting system where anyone could have used those permissions to gain root access you'd have to consider the machine compromised as a whole.

You really don't want to mess up your device permissions like that :-)

It's nice if a simple reboot fixes it

Last edited by frostschutz (2020-01-12 14:39:02)

dreamer3 · 2020-01-12 14:40:30

and if this is a shared hosting system where anyone could have used those permissions to gain root access you'd have to consider the machine compromised as a whole.

For sure. This is just a play/spare system in my house. Thankfully it currently doesn't really have critical data of any kind on it. :-)

I didn't mean revoke, I just meant "correct" the existing permissions on the dev filesystem without needing a reboot... I guess I can manually fix the disks and then put it on the list to reboot later today.

frostschutz · 2020-01-12 14:41:51

if it's just for testing purposes you can always create a new block device with 'losetup --find --show somefile' or plug any usb stick and see if its permissions turn out okay now

dreamer3 · 2020-01-12 14:43:30

Oh, I'm pretty confident a reboot will show it fixed. Unless I have TWO very weird problems lurking. :-) That seems unlikely.

Arch Linux

#1 2020-01-12 13:39:18

/dev Permissions for disks seems all wrong

#2 2020-01-12 13:57:44

Re: /dev Permissions for disks seems all wrong

#3 2020-01-12 13:59:20

Re: /dev Permissions for disks seems all wrong

#4 2020-01-12 14:02:29

Re: /dev Permissions for disks seems all wrong

#5 2020-01-12 14:03:58

Re: /dev Permissions for disks seems all wrong

#6 2020-01-12 14:10:38

Re: /dev Permissions for disks seems all wrong

#7 2020-01-12 14:15:13

Re: /dev Permissions for disks seems all wrong

#8 2020-01-12 14:22:22

Re: /dev Permissions for disks seems all wrong

#9 2020-01-12 14:23:42

Re: /dev Permissions for disks seems all wrong

#10 2020-01-12 14:26:24

Re: /dev Permissions for disks seems all wrong

#11 2020-01-12 14:29:07

Re: /dev Permissions for disks seems all wrong

#12 2020-01-12 14:29:50

Re: /dev Permissions for disks seems all wrong

#13 2020-01-12 14:36:14

Re: /dev Permissions for disks seems all wrong

#14 2020-01-12 14:38:02

Re: /dev Permissions for disks seems all wrong

#15 2020-01-12 14:40:30

Re: /dev Permissions for disks seems all wrong

#16 2020-01-12 14:41:51

Re: /dev Permissions for disks seems all wrong

#17 2020-01-12 14:43:30

Re: /dev Permissions for disks seems all wrong

Board footer