Summary: | app-cdr/cdrtools-3.01_alpha17: installs suid bins, even when USE filecaps is enabled | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Nikoli <nikoli> |
Component: | Current packages | Assignee: | Daniel Pielmeier <billie> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | media-optical, schily |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Nikoli
2013-11-03 14:15:44 UTC
Also i think USE filecaps should be disabled by default or even removed: it turns 0660 permission for /dev/sr0 into 0666. The permissions for /dev/sr0 are unrelated to cdrtools filecaps. Also note that libscg tries to avoid /dev/srx because there is a better driver in /dev/sg* If someone believes that cdrtools work correctly with less than the documented additional privileges,he did not run the right tests. Just because things seem to work under certain conditions, this does neither mean that it did work the best way nor that it will work under other conditions. cdrecord/readcd/cdda2wav either need to be installed suid root or with the documented filecaps. (In reply to Nikoli from comment #0) > Even with USE filecaps enabled several bins are still suid, that seems very > strange and makes usage of libcap completely pointless. Not here. Which several bins? Only rscsi is installed suid root under /usr/sbin here. Filecaps are only applied to cdrecord, cdda2wav and readcd. > I did 3 tests: > 1) With both suid and filecaps enabled recording iso to DVD-RW works fine. This should never be the case. > 2) With filecaps enabled and suid disabled recording iso to DVD-RW works > fine. Which is to be expected. The same goes for disabling filecaps to get the binaries as suid root. > chmod 0755 /usr/bin/cdda2wav /usr/bin/cdrecord /usr/bin/readcd > /usr/sbin/rscsi > 3) With both suid and filecaps disabled recording iso to DVD-RW works fine. Does not work here. Example output from cdrecord: cdrecord: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits. cdrecord: Cannot allocate memory. WARNING: Cannot do mlockall(2). cdrecord: WARNING: This causes a high risk for buffer underruns. cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler. cdrecord: Permission denied. WARNING: Cannot set priority using setpriority(). cdrecord: WARNING: This causes a high risk for buffer underruns. cdrecord: Insufficient 'file read' privileges. You will not be able to open all needed devices. cdrecord: Insufficient 'file write' privileges. You will not be able to open all needed devices. cdrecord: Insufficient 'device' privileges. You may not be able to send all needed SCSI commands, this my cause various unexplainable problems. cdrecord: Insufficient 'memlock' privileges. You may get buffer underruns. cdrecord: Insufficient 'priocntl' privileges. You may get buffer underruns. cdrecord: Insufficient 'network' privileges. You will not be able to do remote SCSI. The filecaps use flag enables the required capabilities and does not install them as suid root. Disabling the use flag installs them suid root. Maybe there is an issue with the fcaps eclass. (In reply to Nikoli from comment #1) > Also i think USE filecaps should be disabled by default or even removed: it > turns 0660 permission for /dev/sr0 into 0666. Not here! Also I don't think cdrtools mess with /dev/sr*. > The permissions for /dev/sr0 are unrelated to cdrtools filecaps. Did not know. > Also note that libscg tries to avoid /dev/srx because there is a better driver in /dev/sg* sg module is installed to /lib/modules/, but udev does not autoload it, so there were no /dev/sg* until i did 'modprobe sg'. Is it udev bug? Also where can i read about why /dev/sg* is better for cdrtools? > cdrecord/readcd/cdda2wav either need to be installed suid root or with the documented filecaps. What problems may happen when both suid and filecaps are disabled? > Not here. Which several bins? Only rscsi is installed suid root under /usr/sbin here. Filecaps are only applied to cdrecord, cdda2wav and readcd. Did 'emerge --sync; emerge -1vba app-cdr/cdrtools'. Now only /usr/sbin/rscsi is 4711, but /usr/bin/{cdda2wav,cdrecord,readcd} are 0711. > > 3) With both suid and filecaps disabled recording iso to DVD-RW works fine. > Does not work here. Example output from cdrecord: What command and device (sr or sg) you were using? I used k3b for testing, will try cli. > Not here! Also I don't think cdrtools mess with /dev/sr*. Then how should permissions for /dev/sg* /dev/sr* and user presence in 'cdrom' group affect usage of cdrtools? (In reply to Nikoli from comment #5) > > Also note that libscg tries to avoid /dev/srx because there is a better > driver in /dev/sg* > > sg module is installed to /lib/modules/, but udev does not autoload it, so > there were no /dev/sg* until i did 'modprobe sg'. Is it udev bug? Also where > can i read about why /dev/sg* is better for cdrtools? I don't know. Maybe it is better to not make this driver a module. Do you use dev=/dev/sr0? You should use the scsibus instead. You will find the bus for your drive with cdrecord -scanbus > > cdrecord/readcd/cdda2wav either need to be installed suid root or with > the documented filecaps. > > What problems may happen when both suid and filecaps are disabled? No problems but you can not use cdrtools as a normal user. > > Not here. Which several bins? Only rscsi is installed suid root under /usr/sbin here. Filecaps are only applied to cdrecord, cdda2wav and readcd. > > Did 'emerge --sync; emerge -1vba app-cdr/cdrtools'. Now only /usr/sbin/rscsi > is 4711, but /usr/bin/{cdda2wav,cdrecord,readcd} are 0711. This is how it should be with filecaps enabled. You can use getcap on the binaries to check the capabilities. > > > 3) With both suid and filecaps disabled recording iso to DVD-RW works fine. > > > Does not work here. Example output from cdrecord: > > What command and device (sr or sg) you were using? I used k3b for testing, > will try cli. cdrecord dev=x,x,x iso I think cdrecord tries to use the sg driver first maybe it falls back to sr if this fails. > > Not here! Also I don't think cdrtools mess with /dev/sr*. > > Then how should permissions for /dev/sg* /dev/sr* and user presence in > 'cdrom' group affect usage of cdrtools? I don't understand your question. The required permissions are defined in the capabilities. If libcap is installed, the kernel and the filesystem supports them everything should be fine. When do you think the cdrecord changes the permissions of /dev/sr0? Are they changed after you use cdrecord? (In reply to Nikoli from comment #5) > > The permissions for /dev/sr0 are unrelated to cdrtools filecaps. > > Did not know. Adding file permissions to everyone and removing restrictions in the linux kernel is a security bug that was introduced in early 2004. Instead of removing an introduced security issue, Torvalds decided to add other problems that allow to partialy hide the problems from the first bug. The current situation is higly copmplex and makes it hard to understand the efects. BTW: the original security issue has been introduced by a driver newcomer (Douglas Gilbert) who misses the skills to know that the original versions of the sg driver on Linux worked based on read(2)/write(2) calls and that thus the sg permissions 644 did only allow root to send SCSI commands. He added an ioctl() to replace the previous read/write based interface and a driver professional would have added a check to the ioctl code that verifies that the driver was opened R/W... > > Also note that libscg tries to avoid /dev/srx because there is a better > driver in /dev/sg* > > sg module is installed to /lib/modules/, but udev does not autoload it, so > there were no /dev/sg* until i did 'modprobe sg'. Is it udev bug? Also where > can i read about why /dev/sg* is better for cdrtools? The last time, I did run scgcheck in order to check the correctness of the SCSI transport system, /dev/sg* was the best on Linux. I remember e.g. problems with reliably getting more DMA space. There is also a repeatedly hitting trap that is caused by the fact that the SCSI implementation in the linux kernel is hosed: e.g. the internal representation of the SCSI status code is shifted by one in the kernel and few kackers are skilled enough to know this. As a result, every other year, someone introduces a related bug in the needlessly replicated code that exists besides /dev/sg. Cdrtools can only work correctly, when it knows the exact cause for a "failed" SCSI command as the SCSI protocol depends the related error codes. > > cdrecord/readcd/cdda2wav either need to be installed suid root or with > the documented filecaps. > > What problems may happen when both suid and filecaps are disabled? I recommend to read the long version in various places on the net. I did repeat this sooooooooo many times before. Note that the claim that there is no problem without having the apropriate privileges is a fairy tale spread by the OSS hostile people from Debian as part of their crusade against the cdrtools. When there recently was a reply at all on the countless problem reports for their so called "fork", they recommended to rerun the command with root privileges ;-) well these prople don't have fine grained priv support. > > Not here. Which several bins? Only rscsi is installed suid root under /usr/sbin here. Filecaps are only applied to cdrecord, cdda2wav and readcd. > > Did 'emerge --sync; emerge -1vba app-cdr/cdrtools'. Now only /usr/sbin/rscsi > is 4711, but /usr/bin/{cdda2wav,cdrecord,readcd} are 0711. OK, if there is really a need, I could create a fine grained enabled version of rscsi. > Then how should permissions for /dev/sg* /dev/sr* and user presence in > 'cdrom' group affect usage of cdrtools? If the commands are run with apropriate privs, the permissions do not affect the behavior. (In reply to joerg.schilling from comment #7) > > > > Not here. Which several bins? Only rscsi is installed suid root under /usr/sbin here. Filecaps are only applied to cdrecord, cdda2wav and readcd. > > > > Did 'emerge --sync; emerge -1vba app-cdr/cdrtools'. Now only /usr/sbin/rscsi > > is 4711, but /usr/bin/{cdda2wav,cdrecord,readcd} are 0711. > > OK, if there is really a need, I could create a fine grained enabled > version of rscsi. > Personally I do not use rscsi, but having rscsi using capabilities instead of being suid root would be beneficial. Also people could get confused if they enable file capabilities but still get rscsi with suid root permissions. (In reply to Daniel Pielmeier from comment #6) > (In reply to Nikoli from comment #5) > cdrecord dev=x,x,x iso > I think cdrecord tries to use the sg driver first maybe it falls back to sr > if this fails. > Correct, libscg is a generic SCSI transport library and it first tries to use the best choice (linux offers more than one driver for a specific hardware) first. If there is no luck, it tries lessoptimal drivers. If the /dev/sg* is not loaded by default, this is a bug. I am closing this bug as I think there is nothing related to cdrtools here. If there are any issues with module loading or other problems a new bug should be opened. Also if it is desired to make rscsi use fine grained privileges there should be a separate bug. |