Bug 451320 - cdrkit needs to handle ACL's
Summary: cdrkit needs to handle ACL's
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: udev
Version: 9
Hardware: i386
OS: Linux
low
low
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 454066 454082 454122 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-13 19:51 UTC by Frantisek Hanzlik
Modified: 2013-01-10 04:43 UTC (History)
22 users (show)

Fixed In Version: 124-1.fc9.2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-14 17:58:23 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Don't reset permissions on media change (923 bytes, patch)
2008-07-03 20:38 UTC, drago01
no flags Details | Diff

Description Frantisek Hanzlik 2008-06-13 19:51:29 UTC
Description of problem:


Version-Release number of selected component (if applicable):
probably hal-0.5.11-2.fc9.i386 from F9 testing repo, build date 12-Jun-2008,
and/or udev-124-1.fc9.i386 from same source

How reproducible:
when ejecting CD/DVD medium - by "eject /dev/sr0" cmd or by Nautilus - then
immediately after is ejected is dragget back into drive. No matter when it is
blank, valid iso or damaged iso medium.
Additionaly, device permission are 0640 (root:disk) even for blank media,
and k3b then cannot access to it.


Steps to Reproduce:
1. Update to hal & udev from F9 testing repo
2. try burn with k3b or mount some CD/DVD
3. eject these with Nautilus or eject command
  
Actual results:
medium is after ejection immediately reinserted into drive.

Expected results:
medium stay ejected


Additional info:

Comment 1 David Zeuthen 2008-06-15 00:46:41 UTC
(In reply to comment #0)
> Additionaly, device permission are 0640 (root:disk) even for blank media,
> and k3b then cannot access to it.

What's the output of 'getfacl /dev/sr0'?

Comment 2 Frantisek Hanzlik 2008-06-15 03:17:29 UTC
Sorry, this output I should add to report first.
After computer reboot and user (hanzlik) log-in, "getfacl /dev/sr0" print:
getfacl: Removing leading '/' from absolute path names
# file: dev/sr0
# owner: root
# group: disk
user::rw-
user:hanzlik:rw-
group::r--
mask::rw-
other::---

But after inserting media, no matter when blank or with ISO image,
"getfacl /dev/sr0" output is:
getfacl: Removing leading '/' from absolute path names
# file: dev/sr0
# owner: root
# group: disk
user::rw-
user:hanzlik:rw-		#effective:r--
group::r--
mask::r--
other::---

user rights are thus stripped by effective rights mask, which was changed.
Blank medium is at desktop properly displayed as blank, and ISO medium is
properly automounted.
While changing mask for ISO image probably isn't too constrictive (but what if I
will wish add another session to multisession CD?), it perhaps disable burn to
blank media.

Comment 3 David Zeuthen 2008-06-15 18:19:02 UTC
As the output says you have an RW ACL for /dev/sr0 ... the "#effective:r--"
_comment_ is misleading because of the fact that /dev/sr0 is a read only device
(but you can still do ioctl's on it, that's the way cd burning works). 

So I believe this is simply a bug in cdrkit (that is used in n-c-b and other
burning tools). So reassigning; cdrkit maintainers: Feel free to assign back if
you can explain I'm wrong. Thanks.

Frantisek: For the reinsertion issue please file a new bug report against hal
(and in the future please don't report multiple bugs in a single bug report).


Comment 4 Frantisek Hanzlik 2008-06-16 10:58:10 UTC
After some fiddling I thing problem is definitely in udev-124-1.fc9.i386.
Dowgrading hal to previous version (hal-libs-0.5.11-1.fc9, hal-0.5.11-1.fc9,
hal-info-20080508-1.fc9, hal-devel-0.5.11-1.fc9) not solved problem.
But after dowgrading udev-124-1.fc9.i386 to original
udev-120-5.20080421git.fc9.i386 all works fine (even I upgrade hal-* again) -
when I eject medium, then it stay ejected, effective rights mask is always
"rw-", k3b startup environment test is
satisfied too (with effective rights mask "r--" k3b at start write:
No write access to device /dev/sr0
K3b needs write access to all the devices to perform certain tasks. Without it
you might encounter problems with TSSTcorp - CDDVDW SH-S203P
Solution: Make sure you have write access to /dev/sr0. In case you are not using
devfs or udev K3bSetup is able to do this for you.
)
It really appear as some udev-124 problem.

Comment 5 David Zeuthen 2008-06-16 16:15:01 UTC
Frantisek: why did you reassign the bug to me? Please stop doing that.

Comment 6 Jesse Keating 2008-06-16 16:34:58 UTC
I too am experiencing this problem, and can certainly pinpoint it to the
udev-124 release.  Starting with a stick F9 system just updating udev will cause
this problem to show up.

David had me change the timing of the pam_console rules from 95 to 89, but that
change had no apparent effect upon the problem.

Triggering the issue is as simple as booting (to GNOME), then inserting media,
or removing already inserted media.  The permissions of the device will resort
back to rw-r-- which imposes a permission mask upon the ACLs preventing the user
from doing anything.

Comment 7 David Zeuthen 2008-06-16 16:36:06 UTC
Reassigning back to HAL until we finds the culprit.

Comment 8 Torsten Rausche 2008-07-02 17:20:46 UTC
Looks like this is the same issue as
https://bugzilla.redhat.com/show_bug.cgi?id=453095

Comment 9 Harald Hoyer 2008-07-03 11:28:16 UTC
well, what sets mode 660 to /dev/sr0 ?? udev sets 0640 initially. 
and in udev-124 the "change" event is also processed, which resets /dev/sr0 to 0640.

Comment 10 Harald Hoyer 2008-07-03 11:31:49 UTC
pam_console does not cover cdrom anymore, btw

Comment 11 Harald Hoyer 2008-07-03 14:27:56 UTC
see also http://thread.gmane.org/gmane.linux.hotplug.devel/12758

Comment 12 Jesse Keating 2008-07-03 17:41:55 UTC
I'm not sure what sets it to 660, but that's what it needs to be.  When it's not
660, if group only has read access, that sets a mask upon any file system ACLs
that might get set, by the likes of policykit.  The net results is that non-root
users are unable to write to the device for things like CD burning.

So maybe the bug here is that the change processing is finally setting things to
what udev thinks they should be, but we've been operating on an assumption that
udev 'thought' it should be 660, and we need to reflect that assumption now.

Comment 13 drago01 2008-07-03 20:38:50 UTC
Created attachment 310962 [details]
Don't reset permissions on media change

The attached patch fixes it by reverting the upstream change that broke it ..
it isn't the cleanest solution but better than breaking cd burning for
everybody. Please consider adding this to an update until a "real" solution is
found upstream.

Comment 14 David Zeuthen 2008-07-03 20:41:14 UTC
(In reply to comment #13)
> Created an attachment (id=310962) [edit]
> Don't reset permissions on media change
> 
> The attached patch fixes it by reverting the upstream change that broke it ..
> it isn't the cleanest solution but better than breaking cd burning for
> everybody. Please consider adding this to an update until a "real" solution is
> found upstream.

NAK. This is going to break DeviceKit-disks (soon to land in Rawhide) and other
things. The real fix is to not mess around with the permissions on 'change' events.


Comment 15 David Zeuthen 2008-07-03 20:41:42 UTC
back to udev btw

Comment 16 Harald Hoyer 2008-07-04 05:57:55 UTC
the fix is wrong, because we need "change" events for other devices

Comment 17 Harald Hoyer 2008-07-04 05:58:06 UTC
and vol_id

Comment 18 Harald Hoyer 2008-07-04 09:44:01 UTC
*** Bug 454066 has been marked as a duplicate of this bug. ***

Comment 19 Harald Hoyer 2008-07-04 09:46:16 UTC
(In reply to comment #15)
> back to udev btw

hmm, udev upstream wants the app, which applied 0660, to apply it again on
change events... so? hal/consolekit?

Comment 20 Kay Sievers 2008-07-04 10:09:30 UTC
The options are: make udev not to change permissions on "change" events, or let
the stuff that applies ACL's do the same thing on "change" as on "add" events.

I think the second option is the right thing to do, because "change" could mean
anything in a device context, including a making a different decision for
granting device access to users. But I'm open any reasonable argument.

Let me know. Thanks!

Comment 21 Harald Hoyer 2008-07-04 14:14:55 UTC
*** Bug 454082 has been marked as a duplicate of this bug. ***

Comment 22 Fedora Update System 2008-07-04 15:32:16 UTC
udev-124-1.fc9.2 has been submitted as an update for Fedora 9

Comment 24 David Nielsen 2008-07-04 23:44:32 UTC
*** Bug 453591 has been marked as a duplicate of this bug. ***

Comment 25 Fedora Update System 2008-07-06 06:14:23 UTC
udev-124-1.fc9.2 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 26 Dirk Strangfeld 2008-07-06 14:14:13 UTC
Okay, the new update fixes the problem with the permissions for reading cd and
dvd media. But the problem with the closing tray is the same.

When ejecting CD/DVD medium, then immediately after is ejected is dragget back
into drive.

Comment 27 Paul Smith 2008-07-06 17:19:01 UTC
> When ejecting CD/DVD medium, then immediately after is ejected is dragget back
> into drive.

The happens here. I do not know how to remove the disk out of the computer...

Paul


Comment 28 John Thacker 2008-07-06 17:46:50 UTC
I'm also still seeing the problem with the disk tray closing immediately after
eject.  Occurs with DVD-Video, DVD-ROM, blanks, etc, regardless of if I use the
eject button on the front of the drive, use the eject command from Nautilus
desktop, or use the umount and eject commands in sequence from the console.

It does seem to eject correctly immediately following a successful burn by
gnomebaker.

Comment 29 John Thacker 2008-07-06 18:10:50 UTC
Oh, and it also ejects normally if there's nothing current in the drive.  It
only ejects and then immediately closes again (after reaching its full extension
briefly) if there is some media in the drive.

Does seem to duplicate bug 453095 but there seems to be more information on this
entry.

Comment 30 Colin Adams 2008-07-07 17:06:47 UTC
I am having a problem - I cannot mount and open my camera (a Nikon D300).

If I try to do so (using USB-PTP), mount it, and then try to open it (with
gThumbImageViewer of FSpot), I get the error:

 An error occurred in the io-library ('Could not lock the device'): Camera is
already in use.

This started happening yesterday. Coincidentally, that was the same date that
udev was upgraded from 124-1.fc9.1 to 124-1.fc9.2 .

Comment 31 Chuck Ebbert 2008-07-09 21:09:36 UTC
*** Bug 454122 has been marked as a duplicate of this bug. ***

Comment 32 Christian Krause 2008-07-14 20:01:55 UTC
(In reply to comment #29)
> Oh, and it also ejects normally if there's nothing current in the drive.  It
> only ejects and then immediately closes again (after reaching its full extension
> briefly) if there is some media in the drive.

The same problem happens on my machine. I've tested a little bit with different
versions of the hal daemon and udev and it looks like that the problem is
triggered definitively by udevd:

- installing different versions of hal daemon: no change
- installing F9 release version of udev (udev-120-5.20080421git.fc9.i386.rpm):
problem does _not_ happen any more

Comment 33 Adam Pribyl 2008-07-21 17:35:12 UTC
I think this bug should be closed as permissions are fixed in latest udev
update. The separate bug 453095 is about tray beiing closed immediately.

Comment 34 Adam Hough 2008-08-14 18:50:30 UTC
I am currently running F9 with the latest updates and am seeing this issue.  I do not believe it is fixed.

Comment 35 Adam Hough 2008-08-14 18:58:37 UTC
I may actually be seeing this (https://bugzilla.redhat.com/show_bug.cgi?id=423641 ) bug or these may be related bugs somehow.

Comment 36 Bug Zapper 2009-06-10 01:35:47 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 37 Bug Zapper 2009-07-14 17:58:23 UTC
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.