CD/DVD problem after update on 24/oct

mapester · 2011-10-25 12:46:09

Yesterday i did a Pacman -Syu on my arch box that i primarily use to run XBMC, it gave a warning "We no longer create symlinks from /dev/<dev> to /dev/<dev>0" with something about storage group is/or has a security risk and for usual functionality users should make udev rules.

i've google'd / tried the search on forums and i found this

Custom CD-ROM symlinks
SUBSYSTEM=="block", KERNEL=="sr0", SYMLINK+="cdrom cdrw dvd dvdrw"

to create a file in /etc/udev/rules.d called 82-cdrom.rules with above content.

i've tried this and now the DVD/CD drive is showing its mounted, but when i try access it via xbmc it is not mounted or is inaccessible.

.:B:. · 2011-10-25 13:40:03

Probably a permissions issue.

nemesis2all · 2011-10-25 14:09:18

Udev is no longer making your CD drive part of the optical group. It is in the disk group. Quickest fix is to add yourself to that group.

# gpasswd -a yourusername disk

Alternatively you can add this to your udev rule to make your CD/DVD drive belong to the optical group again.

# permissions for IDE CD devices
SUBSYSTEMS=="ide", KERNEL=="hd[a-z]", ATTR{removable}=="1", ATTRS{media}=="cdrom*", GROUP="optical"

# permissions for SCSI CD devices
SUBSYSTEMS=="scsi", KERNEL=="s[rg][0-9]*", ATTRS{type}=="5", GROUP="optical"

Last edited by nemesis2all (2011-10-25 14:12:30)

mapester · 2011-10-25 15:04:46

This worked perfectly, thanks for the quick reply + solution.

nemesis2all wrote:

Udev is no longer making your CD drive part of the optical group. It is in the disk group. Quickest fix is to add yourself to that group.
# gpasswd -a yourusername disk
Alternatively you can add this to your udev rule to make your CD/DVD drive belong to the optical group again.
# permissions for IDE CD devices
SUBSYSTEMS=="ide", KERNEL=="hd[a-z]", ATTR{removable}=="1", ATTRS{media}=="cdrom*", GROUP="optical"

# permissions for SCSI CD devices
SUBSYSTEMS=="scsi", KERNEL=="s[rg][0-9]*", ATTRS{type}=="5", GROUP="optical"

Misfit138 · 2011-10-25 21:14:34

Adding a nonroot user to the disk group may be frowned upon by the security conscious. A simpler and potentially more secure solution can be found here.

Gusar · 2011-10-25 21:50:35

Misfit138 wrote:

Adding a nonroot user to the disk group may be frowned upon by the security conscious. A simpler and potentially more secure solution can be found here.

There's also the udev approach - /etc/udev/rules.d/82-cdrom.rules

SUBSYSTEMS=="scsi", KERNEL=="sr0", SYMLINK+="cdrom dvd"

You could combine this and the rule for the optical group in the same file for a complete setup.

Though now my question is... What was the point of removing those rules, when they're widely useful and we're now instructing users to add them back?

Laertes · 2011-10-26 18:50:19

Is this causing problems with other groups as well? Since I updated to udev 174 I can not start Xfce. I can log in with kdm but after that the screen remains blank. Can it be that devices are not allocated to the video group? If I switch to text console with Ctrl+Alt+F1 I can log in, but a lot of erros about /dev/null clutter the screen and the locale is not set. The only solution I've found is to switch back to udev 173.

I think that the udev update is not clearly explained. It should mention that it will break the system and that manual action is required, like it has been done for example with the recent initscripts change.

rene · 2011-10-26 22:39:04

Thank you, nemesis2all, #3.

If anyone has trouble with brasero failing to eject at the end of a burn after fixing this issue in the #3 way, also see:

https://bugs.archlinux.org/task/20035#comment84866

The short: don't remove your user from the "storage" group even though it appears not needed anymore.

nemesis2all · 2011-10-26 23:24:08

Gusar wrote:

Though now my question is... What was the point of removing those rules, when they're widely useful and we're now instructing users to add them back?

I'd like to know that as well. I hear there are more changes in store for udev so maybe this will be addressed in an update. I'm just sitting back and waiting to see what will end up being the preferred method to handle optical disks for non root users.

arriagga · 2011-10-26 23:38:33

this udev upgrade also breaks nero linux so I had to downgrade udev.

ninian · 2011-10-26 23:49:34

arriagga wrote:

this udev upgrade also breaks nero linux so I had to downgrade udev.

It's okay - Nero problem fixed in a jiffy by loading the 'sg' module!
See https://bbs.archlinux.org/viewtopic.php?pid=1008599

arriagga · 2011-10-27 00:30:24

How do I load the sg module?

ConnorBehan · 2011-10-27 03:32:13

The same way you load any module... "sudo modprobe sg".

The rc.local method is probably more secure than creating the symlinks with a udev rule. But by then it is too late for the files on optical discs to be mounted when your fstab is parsed (if you put /dev/dvd and /dev/cdrom in there). Since I'm not very security conscious I instead have a script in my rc.local that will continuously add my user to any newly created group that might not include him.

Gusar · 2011-10-27 11:51:06

Why would the udev method be insecure? That's what udev is for (well, one of the things it's for)!

skanky · 2011-10-28 09:40:41

I'm a little unsure about some of the suggested fixes for this. The issue is a permissions issue, in that sr0 is no longer in optical. The obvious answer is to add the user to disks, but this has security implications.

Adding symlinks isn't going to resolve the fact that sr0 is in disk and not optical - or am I missing something obvious here?

Apart from the udev rule to add sr0 to optical (which isn't working for me at the moment, but that's probably some error in my implementation which I'll try and sort out today), what other ways to resolve the permissions issue are there?

Gusar · 2011-10-28 10:31:58

skanky wrote:

Adding symlinks isn't going to resolve the fact that sr0 is in disk and not optical - or am I missing something obvious here?

No, you're not missing anything. The symlinks rule is just a convenience, because many apps look for /dev/cdrom or /dev/dvd as the default device. And if you have the symlinks, those apps will work without requiring configuration.

It's the other rule, the one that assigns devices to the optical group, that is a better solution than using the disk group. That's why I said "You could combine [both rules] in the same file for a complete setup."

skanky · 2011-10-28 10:50:47

Gusar wrote:

skanky wrote:
Adding symlinks isn't going to resolve the fact that sr0 is in disk and not optical - or am I missing something obvious here?
No, you're not missing anything. The symlinks rule is just a convenience, because many apps look for /dev/cdrom or /dev/dvd as the default device. And if you have the symlinks, those apps will work without requiring configuration.
It's the other rule, the one that assigns devices to the optical group, that is a better solution than using the disk group. That's why I said "You could combine [both rules] in the same file for a complete setup."

Okay that makes sense, many thanks. I'll get my udev rule working.

tomegun · 2011-10-30 14:22:27

Hi guys,

A few clarifications / questions:

1) your cdrom drive should be in the "optical" group, if it is not this is a bug (in kernel or udev). Please open a report and I'll look into it.

2) the symlinks: the reason these are no longer supported can best be described as:
a) in case you only have one optical device, you can just describe it as /dev/sr0, there is no ambiguity.
b) in case you have more than one optical device, it is (almost) random which one is called /dev/sr0, and hence which is linked to by /dev/cdrom. In other words, a program needs to use something else than the name of the node in order to identify the device (most apps do). If there are still apps using /dev/cdrom, please open reports and tell them to at least move to /dev/sr0 instead (and cc me if you can).

3) modprobe sg: this should never be needed. If it is, it is a bug in udev or kernel (or your setup, though I'm not sure what that could be). Please open a report and I'll look into it.

In the reports for 1 and 3, we'll at least need the output of "udevadm info -a -n /dev/sr0" (assuming that is the name of your device), and it would be best if you can reproduce the problem and give the debug output without any custom udev rules installed (in /etc/udev/rules.d), and no custom module options/blacklisting (in /etc/modprobe.d).

Cheers,

Tom

PS

Someone asked about "why would the udev method be insecure". I'm not sure exactly what is meant, but I can clarify the security concerns that caused us to drop our custom "storage" support:

The point is that you should not need to be in any groups by default in order to use your computer, but udev, consolekit, policykit, udisks and upower should make things work for you. The principle is there that the user who is logged on to the machine and sitting in front of it has permissions to use the hardware connected to it. The problem with using groups to do the same is that all users can access all the devices at the same time, no matter how they log in. E.g. a remote user could listen to your microphone, or copy the contents of your usbdrive. Using ConsoleKit we avoid this problem.

We finally dropped the storage group, when it turned out that our implementation was buggy, it was not clear how to fix it, and upstream was not interested in taking our patches (the last point is in itself reason good enough to let it go).

[Edit: to add that you should make sure no modules are blacklisted before reporting the bugs]

Last edited by tomegun (2011-10-30 14:24:55)

nemesis2all · 2011-10-30 15:31:02

@ tomegun

Thank you very much for your clarification. Upon reading your response I went thru and deleted my custom udev rules and symlinks in /etc/rc.local for optical drives. It looks like the beginner's guide should be updated to reflect this. I think the issue many are having is with the symlinks in /etc/rc.local, it is creating your device in root group. Which in turn users are having to work around that with how the udev 174-1 has changed. After I changed everything up without symlinks and custom udev rules I was able to play a DVD in vlc player as long as a changed the source to /dev/sr0.

edit 1 I think this should be removed from the wiki https://wiki.archlinux.org/index.php/Be … M_symlinks

edit 2 To clarify, I am able to play DVDs even tho /der/sr0 is owned by disk group and I'm not a member of that group. I have not tried to burn any discs with this setup yet. Will report back when I know if that works. I assume most multimedia, and CD recording applications will have to be updated to look to /dev/sr0 instread of /dev/dvd, /dev/cdrw, etc.

Last edited by nemesis2all (2011-10-31 03:22:44)

tesjo · 2011-10-31 02:49:02

I can confirm my /dev/sr0 is in the 'disk' group and it seems the bug report is already open.

https://bugs.archlinux.org/task/26640

skanky · 2011-10-31 11:46:07

@tomegun thanks for the clarification.

The issue seems to be as is discussed in the bug linked to by tesjo, in that /dev/sr0 is in root.disk. I don't have any /dev/sg* devices.
I also do not have consolekit installed.

I'm not sure if that information would be useful in the bug report or redundant.

FIlIPy65 · 2011-11-02 17:29:06

ninian wrote:

arriagga wrote:
this udev upgrade also breaks nero linux so I had to downgrade udev.
It's okay - Nero problem fixed in a jiffy by loading the 'sg' module!
See https://bbs.archlinux.org/viewtopic.php?pid=1008599

Thank you so much, it helped me a lot.

tomegun · 2011-11-06 23:34:00

skanky wrote:

The issue seems to be as is discussed in the bug linked to by tesjo, in that /dev/sr0 is in root.disk.

This is indeed a bug in the current udev, which can be fixed by adding a new rules /etc/udev/rules.d/51-tmp-optical-fix.rules containing

SUBSYSTEM=="block", KERNEL=="sr[0-9]*". GROUP="optical"

Remember to remove it once udev-175 is out.

skanky wrote:

I don't have any /dev/sg* devices.

Contrary to what I wrote above, this is expected. You should not need the /dev/sgX devices in most circumstances, but if you do you should add 'sg' to MODULES in rc.conf. If Nero needs this, one can only hope that they will switch to either using the /dev/bsgX devices or the /dev/srY devices instead.

skanky wrote:

I also do not have consolekit installed.

The best way for this stuff to "just work" is to use consolekit (assuming your DM has support for it, or you have manually set it up correctly).

skanky · 2011-11-07 09:54:10

tomegun wrote:

skanky wrote:
The issue seems to be as is discussed in the bug linked to by tesjo, in that /dev/sr0 is in root.disk.
This is indeed a bug in the current udev, which can be fixed by adding a new rules /etc/udev/rules.d/51-tmp-optical-fix.rules containing
SUBSYSTEM=="block", KERNEL=="sr[0-9]*". GROUP="optical"
Remember to remove it once udev-175 is out.
skanky wrote:
I don't have any /dev/sg* devices.
Contrary to what I wrote above, this is expected. You should not need the /dev/sgX devices in most circumstances, but if you do you should add 'sg' to MODULES in rc.conf. If Nero needs this, one can only hope that they will switch to either using the /dev/bsgX devices or the /dev/srY devices instead.
skanky wrote:
I also do not have consolekit installed.
The best way for this stuff to "just work" is to use consolekit (assuming your DM has support for it, or you have manually set it up correctly).

Many thanks for the update. I'll add the udev rule for now and wait for the update.

I don't use a DM, and never really saw a need for it before. I'll maybe look into it if I have any more issues.

Again, many thanks.

skanky · 2011-11-09 09:55:11

Latest udev fixed my issues. Thanks to all, and esp tomegun.

Arch Linux

#1 2011-10-25 12:46:09

CD/DVD problem after update on 24/oct

#2 2011-10-25 13:40:03

Re: CD/DVD problem after update on 24/oct

#3 2011-10-25 14:09:18

Re: CD/DVD problem after update on 24/oct

#4 2011-10-25 15:04:46

Re: CD/DVD problem after update on 24/oct

#5 2011-10-25 21:14:34

Re: CD/DVD problem after update on 24/oct

#6 2011-10-25 21:50:35

Re: CD/DVD problem after update on 24/oct

#7 2011-10-26 18:50:19

Re: CD/DVD problem after update on 24/oct

#8 2011-10-26 22:39:04

Re: CD/DVD problem after update on 24/oct

#9 2011-10-26 23:24:08

Re: CD/DVD problem after update on 24/oct

#10 2011-10-26 23:38:33

Re: CD/DVD problem after update on 24/oct

#11 2011-10-26 23:49:34

Re: CD/DVD problem after update on 24/oct

#12 2011-10-27 00:30:24

Re: CD/DVD problem after update on 24/oct

#13 2011-10-27 03:32:13

Re: CD/DVD problem after update on 24/oct

#14 2011-10-27 11:51:06

Re: CD/DVD problem after update on 24/oct

#15 2011-10-28 09:40:41

Re: CD/DVD problem after update on 24/oct

#16 2011-10-28 10:31:58

Re: CD/DVD problem after update on 24/oct

#17 2011-10-28 10:50:47

Re: CD/DVD problem after update on 24/oct

#18 2011-10-30 14:22:27

Re: CD/DVD problem after update on 24/oct

#19 2011-10-30 15:31:02

Re: CD/DVD problem after update on 24/oct

#20 2011-10-31 02:49:02

Re: CD/DVD problem after update on 24/oct

#21 2011-10-31 11:46:07

Re: CD/DVD problem after update on 24/oct

#22 2011-11-02 17:29:06

Re: CD/DVD problem after update on 24/oct

#23 2011-11-06 23:34:00

Re: CD/DVD problem after update on 24/oct

#24 2011-11-07 09:54:10

Re: CD/DVD problem after update on 24/oct

#25 2011-11-09 09:55:11

Re: CD/DVD problem after update on 24/oct

Board footer