devfs
[Top] [All Lists]

Re: /dev/cdrom and devfs v213

To: Borsenkow Andrej <Andrej.Borsenkow@xxxxxxxxxxxxxx>
Subject: Re: /dev/cdrom and devfs v213
From: A Guy Called Tyketto <tyketto@xxxxxxxxxx>
Date: Mon, 20 May 2002 01:19:44 -0700
Cc: devfs@xxxxxxxxxxx
In-reply-to: <Pine.SV4.4.44.0205201131160.25739-100000@xxxxxxxxxxxxxxxxxxxxx>
References: <20020519235822.GA298@xxxxxxxxxx> <Pine.SV4.4.44.0205201131160.25739-100000@xxxxxxxxxxxxxxxxxxxxx>
Sender: owner-devfs@xxxxxxxxxxx
User-agent: Mutt/1.3.28i
On Mon, May 20, 2002 at 11:34:37AM +0400, Borsenkow Andrej wrote:
> On Sun, 19 May 2002, A Guy Called Tyketto wrote:
> 
> >
> >         Aye, but the location of the entry and permissions in either file
> > really have nothing to do with why the device is not usable by a non-root
> > user, when given permissions 0666, or even 0660:
> >
> 
> It is usable. As your strace shows, user can read CD just fine. It is one
> particular IOCTL that fails.
> 
> May be 2.5 put some restrictions on who can use this ioctl?
> 
> -andrej

        Hmm.. You may be right. I fell back to 2.5.7, did an strace on 
workbone, and got:

open("/dev/cdrom", O_RDONLY)            = 3  "..., 55
ioctl(3, CDROMSUBCHNL, 0xbfffe654)      = 0
ioctl(3, CDROMREADTOCHDR, 0xbfffe626)   = 0
ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0
ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0
ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0
ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0
ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0
ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0
ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0
ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0
ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0
ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0
ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0
ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0
ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_START, {B38400 opost isig -icanon -echo ...}) = 0
ioctl(0, TCGETS, {B38400 opost isig -icanon -echo ...}) = 0

        Which is normal, as it's waiting for user input on the number pad. in 
2.5.16, it throws you back out to your prompt, with the trace previously 
posted. I'll throw this over to the LKML, along with another unrelated issue I 
have with 2.5.

                                                        BL.

<Prev in Thread] Current Thread [Next in Thread>