Re: cdrecord and newer Linux kernels

[Steve McIntyre <steve@einval.com>]

[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]

On Wed, Nov 16, 2005 at 12:39:03PM +0900, Horms wrote:
>In article <20051111000913.GU4682@einval.com> you wrote:
>> 
>> That does make it rather difficult to have any safe CD/DVD writing
>> software - do you think it's a good idea to have end users run apps as
>> root to burn CDs? I've read too much of the cdrecord source to be
>> happy running that as root! :-) My thought is that it might be better
>> to allow specific commands on specific drives, and let the local admin
>> configure that for themselves...
>> 
>
>The whole problem is that some IOCTLS are not safe. And there is no
>definitive list of IOCTLs, so safe ones are added as they are known. And
>the others are disabled.  If you have discovered ioctls which are indeed
>safe, then they should be added to the whitelist.
>
>As for allowing root to have a mechanism to allow users to access
>arbitary (unsafe) ioctls, that sounds like a can of worms to me.
>I have CCed the SCSI maintainers for comment.
>
>For their reference, your original post and patch, allong with
>the rest of this thread is at:
>
>http://lists.debian.org/debian-kernel/2005/11/msg00748.html

Again, I understand why the checks were added to the kernel. Adding
access controls to limit the damage that could be caused by non-root
users is entirely a good plan!

The reason I'm looking into this is that there are some commands that
may be dangerous on some devices but on others harmless / useful /
required (even); several years of writing SCSI-based storage
management software has show me that. :-) Allowing a mechanism for an
admin to override the in-kernel policy on a per-device, per-command
basis could allow us to safely allow non-root CD/DVD burning, I hope.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
Google-bait:
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]