K3b and 2.6.9?

K3b and 2.6.9?

[Tim Fairchild]

Hi. Sorry for the silly question from a user who can't code their way out of a 
paper bag, but I have compiled 2.6.9-rc1-bk5 and currently running okay (the 
nvidia module will now compile) with no oops so far. But K3B still does not 
work - as with 2.6.8.1. 

Am I right in assuming that this is the way things will be done in the kernel 
from now on and that we will need new versions of k3b/cdrecord to run with 
these newer kernels? 

Without knowing a better way, I am currently using the same sort of quick 
patch as 2.6.8.1 to use k3b on 2.6.9-rc1-bk5 ie:

--- a/drivers/block/scsi_ioctl.c        2004-08-30 03:52:08.000000000 +1000
+++ b/drivers/block/scsi_ioctl.c        2004-08-30 09:31:44.955159390 +1000
@@ -220,9 +220,9 @@
                return -EINVAL;
        if (copy_from_user(cmd, hdr->cmdp, hdr->cmd_len))
                return -EFAULT;
-       if (verify_command(file, cmd))
+/*     if (verify_command(file, cmd))
                return -EPERM;
-
+*/
        /*
         * we'll do that later
         */


--tim

Re: K3b and 2.6.9?

[Alan Cox]

On Llu, 2004-08-30 at 01:47, Tim Fairchild wrote:
> Am I right in assuming that this is the way things will be done in the kernel 
> from now on and that we will need new versions of k3b/cdrecord to run with 
> these newer kernels? 

Folks are working on getting the verify_command list refined, or you 
can run the burner part of cd-burners setuid (as cdrecord supports -
although get the newest one since there was a security hole fixed a few
days ago in both cdrecord and star).

> Without knowing a better way, I am currently using the same sort of quick 
> patch as 2.6.8.1 to use k3b on 2.6.9-rc1-bk5 ie:

Providing you don't mind any of your users erasing your drive firmware
and turning the drive into a brick its fine. 

Re: K3b and 2.6.9?

[Tim Fairchild]

On Monday 30 Aug 2004 23:07, Alan Cox wrote:

> Folks are working on getting the verify_command list refined, or you
> can run the burner part of cd-burners setuid (as cdrecord supports -
> although get the newest one since there was a security hole fixed a few
> days ago in both cdrecord and star).
>
> > Without knowing a better way, I am currently using the same sort of quick
> > patch as 2.6.8.1 to use k3b on 2.6.9-rc1-bk5 ie:
>
> Providing you don't mind any of your users erasing your drive firmware
> and turning the drive into a brick its fine.

Thanks. Yes I realize that and understand why this is a good idea to have. But 
most of the verify_command list seems fine and I find the following works, 
but don't know if this is any 'safer' or not... This is the particular test 
that makes the difference to k3b/cdrecord, but I don't know enough to work 
out what it actually does... (this is with 2.6.9-rc1-bk6) 

--- a/drivers/block/scsi_ioctl.c.original  2004-08-30 23:50:16.000000000 +1000
+++ b/drivers/block/scsi_ioctl.c  2004-08-31 08:37:56.000000000 +1000
@@ -192,7 +192,7 @@

        /* Write-safe commands just require a writable open.. */
        if (type & CMD_WRITE_SAFE) {
-               if (file->f_mode & FMODE_WRITE)
+/*              if (file->f_mode & FMODE_WRITE)      */
                        return 0;
        }

Re: K3b and 2.6.9?

[Linus Torvalds]

On Tue, 31 Aug 2004, Tim Fairchild wrote:
> 
> Thanks. Yes I realize that and understand why this is a good idea to
> have. But most of the verify_command list seems fine and I find the
> following works, but don't know if this is any 'safer' or not... This is
> the particular test that makes the difference to k3b/cdrecord, but I
> don't know enough to work out what it actually does... (this is with
> 2.6.9-rc1-bk6)
> 
> --- a/drivers/block/scsi_ioctl.c.original  2004-08-30 23:50:16.000000000 +1000
> +++ b/drivers/block/scsi_ioctl.c  2004-08-31 08:37:56.000000000 +1000
> @@ -192,7 +192,7 @@
> 
>         /* Write-safe commands just require a writable open.. */
>         if (type & CMD_WRITE_SAFE) {
> -               if (file->f_mode & FMODE_WRITE)
> +/*              if (file->f_mode & FMODE_WRITE)      */
>                         return 0;
>         }

Ehh.. This seems to imply that K3b opens the device for _reading_ when it 
wants to burn a CD-ROM. It also implies that K3b only uses the commands 
that are already marked as being "safe for writing", so the kernel command 
list is apparently fine. 

Which implies that the only way to fix it sanely is literally to have K3b 
open the device for writing, and then everything will be happy.

As far as I can tell, the fix should be a simple one-liner: make sure that 
K3b opens the device with O_RDWR | O_NONBLOCK instead of using O_RDONLY | 
O_NONBLOCK. The fix looks trivial, it's in

   src/device/k3bdevice.cpp:
	int K3bCdDevice::openDevice( const char* name );

(two places).

That "kind of" makes sense anyway - if you want to write to the disk, you 
damn well should open the disk for writing, no? So clearly K3b right now 
is doing something pretty nonsensical.

Can somebody who is active in the K3b community check with the K3b 
authors, and please try to get that fixed?

			Linus

Re: K3b and 2.6.9?

[Frank Steiner]

Linus Torvalds wrote:

> Ehh.. This seems to imply that K3b opens the device for _reading_ when it 
> wants to burn a CD-ROM. 

It seems that this problem is not K3B-only:

Marc Ballarin wrote:

> growisofs and dvd+r-format open the device read-only, even though they try
> to do writes.
 >
> ...
>
> 2) replace O_RDONLY in dvd+r-tools sources with O_RDWR and recompile
> (that's what I did).


cu,
Frank

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049

Re: K3b and 2.6.9?

[Linus Torvalds]

On Tue, 31 Aug 2004, Frank Steiner wrote:

> Linus Torvalds wrote:
> 
> > Ehh.. This seems to imply that K3b opens the device for _reading_ when it 
> > wants to burn a CD-ROM. 
> 
> It seems that this problem is not K3B-only:

Yes. I suspect that these projects have at least looked at each other, so 
it's probably a problem that has its basis in cdrecord or some "original" 
program.

And yes, opening for reading used to work. After all, you didn't need a 
"write()" system call, and the ioctl functions didn't use to check. It's a 
potential security problem, and one that 2.6.8 fixed, and I don't think 
we're willing to go back to the old setup.

And trust me - I absolutely _hate_ breaking user-level programs. I'd love
to unbreak it from the kernel, but in this case I don't see any
alternatives, really.

			Linus

Re: K3b and 2.6.9?

[Tim Fairchild]

On Tuesday 31 Aug 2004 12:29, Linus Torvalds wrote:

> Ehh.. This seems to imply that K3b opens the device for _reading_ when it
> wants to burn a CD-ROM. It also implies that K3b only uses the commands
> that are already marked as being "safe for writing", so the kernel command
> list is apparently fine.

On starting k3b seems to use 'safe for reading' commands and 'safe for 
writing' command 0x55 (mode_select?) to test the drive function. file->f_mode 
is returning with 0x0d during 'safe for writing' command.

growisofs also is returning file->f_mode as 0x0d with any 'safe for writing' 
command if I disable the line and allow k3b to run and burn dvd and just 
printk the cmd and file->f_mode values ... 

I believe FMODE_WRITE is 0x02  tho don't know where that is defined... If this 
bit not set does it mean the device is opened for reading? during a burn? 
Sorry, I'm very new to this... but do notice that cdrecord returnes 0x0f 
which does have the bit set correctly...

tim

Re: K3b and 2.6.9?

[Linus Torvalds]

On Tue, 31 Aug 2004, Tim Fairchild wrote:
> 
> On starting k3b seems to use 'safe for reading' commands and 'safe for 
> writing' command 0x55 (mode_select?) to test the drive function.

Yes. MODE_SELECT is write-only, because that command can do some bad 
things.

> file->f_mode is returning with 0x0d during 'safe for writing' command.

Yes, that's FMODE_READ | FMODE_LSEEK | FMODE_PREAD (ie the device not only 
accepts reading, it can do seeks and "pread()" too). Which is what a block 
device that was opened with O_RDONLY would have.

> I believe FMODE_WRITE is 0x02  tho don't know where that is defined...

Correct. It's a kernel-internal "readability" thing, defined in 
<linux/fs.h> - it's invisible to user space (user space uses the O_RDONLY, 
O_WRONLY and O_RDWR defines, which are in a different numbering space)

> If this bit not set does it mean the device is opened for reading?

Yes, it means that the user used O_RDONLY to open the device.

> during a burn? 

I agree, it doesn't make much sense, does it? But the fact is, it used to 
work, and as a result programs can do it that way because they were tested 
that wat.

Linus' law: programs don't do things because they make sense. Programs do 
things that happened to work for the programmer.

But exactly _because_ it makes so much sense to just change K3b to use
O_RDWR in its open, I'm hoping that the K3b developers won't complain too
much about the kernel changing to require more strict checking (obviously,
I can understand that _users_ will complain - they only see the "it
stopped working" part).

		Linus

Re: K3b and 2.6.9?

[Tim Fairchild]

On Wednesday 01 Sep 2004 03:05,  Linus Torvalds wrote:

> But exactly _because_ it makes so much sense to just change K3b to use
> O_RDWR in its open, I'm hoping that the K3b developers won't complain too
> much about the kernel changing to require more strict checking (obviously,
> I can understand that _users_ will complain - they only see the "it
> stopped working" part).

Thanks for the info. Yes, this is what I am seeing a lot on linux user 
lists... "Don't use kernel 2.6.8.1 - it is broken" and so forth. Which is why 
I was looking to gain some insight into the k3b problem so I feel I know a 
little about the subject when on the lists... And also like to do testing 
when I can to help... what little help it might be.

thanks,

tim

Re: K3b and 2.6.9?

[ismail dönmez]

On Mon, 30 Aug 2004 19:29:53 -0700 (PDT), Linus Torvalds
<torvalds@osdl.org> wrote:

> Which implies that the only way to fix it sanely is literally to have K3b
> open the device for writing, and then everything will be happy.
> 
> As far as I can tell, the fix should be a simple one-liner: make sure that
> K3b opens the device with O_RDWR | O_NONBLOCK instead of using O_RDONLY |
> O_NONBLOCK. The fix looks trivial, it's in
> 
>    src/device/k3bdevice.cpp:
>         int K3bCdDevice::openDevice( const char* name );
> 
> (two places).
> 

Checked k3b on CVS and it does this now :

  int flags = O_NONBLOCK;
  if( write )
    flags |= O_RDWR;
  else
    flags |= O_RDONLY;
.....
  fd = ::open( name, flags );

which already fixes the issue. Right?

Cheers,
ismail

-- 
Time is what you make of it

Re: K3b and 2.6.9?

[Linus Torvalds]

On Tue, 31 Aug 2004, ismail dönmez wrote:
> 
> Checked k3b on CVS and it does this now :
> 
>   int flags = O_NONBLOCK;
>   if( write )
>     flags |= O_RDWR;
>   else
>     flags |= O_RDONLY;
> .....
>   fd = ::open( name, flags );
> 
> which already fixes the issue. Right?

I assume so, assuming that the "write" flag is set correctly. Somebody 
would need to test whether it actually works for them ;)

		Linus

Re: K3b and 2.6.9?

[Tim Fairchild]

On Wednesday 01 Sep 2004 06:33, Linus Torvalds wrote:
> On Tue, 31 Aug 2004, ismail dönmez wrote:
> > Checked k3b on CVS and it does this now :
> >
> >   int flags = O_NONBLOCK;
> >   if( write )
> >     flags |= O_RDWR;
> >   else
> >     flags |= O_RDONLY;
> > .....
> >   fd = ::open( name, flags );
> >
> > which already fixes the issue. Right?
>
> I assume so, assuming that the "write" flag is set correctly. Somebody
> would need to test whether it actually works for them ;)

Will test more here as soon as possible which may be a couple of days as I 
will be away from the computer...

Thanks all very much.

tim

Re: K3b and 2.6.9?

[Tim Fairchild]

On Wednesday 01 Sep 2004 06:33, Linus Torvalds wrote:
> On Tue, 31 Aug 2004, ismail dönmez wrote:
> > Checked k3b on CVS and it does this now :
> >
> >   int flags = O_NONBLOCK;
> >   if( write )
> >     flags |= O_RDWR;
> >   else
> >     flags |= O_RDONLY;
> > .....
> >   fd = ::open( name, flags );
> >
> > which already fixes the issue. Right?
>
> I assume so, assuming that the "write" flag is set correctly. Somebody
> would need to test whether it actually works for them ;)

I can't seem to easily get the cvs to compile on my box at the moment, but 
making these changes to the k3b-0.11.14 code seems to be working here, tho 
k3b seems to always open as write now. Haven't looked at latest dvd+rw-tools 
but they would be similar I guess...

tim