Bill Davidsen <[EMAIL PROTECTED]> wrote: > > cdrecord works without real problems on Linux-2.6 if you install it > > correctly > > suid root. > > > Unfortunately "run everything as root" is not going to happen on many > systems, some years ago capabilities were added to Linux, and those are > the proper way to do access rather than bypassing all security checks. > Also, the last time I looked the notes you provided only worked if > security was disabled, selinux won't let you do what you were suggesting.
Looks like you are uninformed :-( Currently there is no more than something in pre-alpha state that could later become a fine grained security modell (once there is support in userland). Check out "man privileges" on Solaris for more information on what makes a ready to use system in this area. On Solaris, cdrecord really runs without root privileges. On Solaris, /usr/bin/cdrecord is a shell script with the following content: #!/bin/sh pfexec "`dirname $0`/`basename $0`.bin" "$@" The file /etc/security/exec_attr contains the following entries for cdrtools: Basic Solaris User:solaris:cmd:::/usr/bin/cdrecord.bin:privs=file_dac_read,sys_devices,proc_lock_memory,proc_priocntl,net_privaddr Basic Solaris User:solaris:cmd:::/usr/bin/cdda2wav.bin:privs=file_dac_read,sys_devices,proc_priocntl,net_privadd Basic Solaris User:solaris:cmd:::/usr/bin/readcd.bin:privs=file_dac_read,sys_devices,net_privaddr Once Linux implements a user ready version of the current experimental interface, it would make sense to let cdrtools use this interface. > > Some old versions do not but this is caused by non-cooperative acting > > from the Linux Kernel maintainers: they did introduce a severe incompatible > > interface change after cdrtools had been put into a code freeze state > > for releasing. > Caused by fixing a serious security issue... Once the first exploit was > out it did have to be done quickly, and it did impact applications (not > just yours). It came at a bad time in your code cycle, but making it > sound as if the change was made just because they felt like it is simply > not true. Allowing any SCSI command to go to devices was a hole allowing > the bad guys to wipe out firmware on hard drives as well as burners, and > had to be stopped immediately. You are again uninformed: The security issue was: "sending of SCSI commands was possible on file descriptors opened with O_RDONLY". The correct fix for this security bug was to require "O_RDWR" instead of "O_RDONLY". This did not harm interfaces but cure the problem. The problem was that Mr. Torvalds did introduce an incompatible interface change instead although many people on LKML did send their protest mails. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]