Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Pascal Schmidt]

On Sat, 21 Aug 2004 14:50:08 +0200, you wrote in linux.kernel:

> If the owners and permissions of the filesystem have been set up correctly,
> then there is no security problem. 

The previous Linux implementation allowed users with *read* access
to the device to send arbitrary SG_IO commands. Giving read permission
to normal users is quite common, to allow them to run isosize or play
their freshly burned SVCDs with mplayer.

It violated the principle of least surprise that a user can screw
the device without even having write permission.

Yes, it breaks user-space programs, and yes, the kernel is to blame
for its previous behavior, not user-space. However, now we need to
get on, and going back to the previous behavior, which because
the discussion is now a well-known security hole, is not an option.

-- 
Ciao,
Pascal

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Pascal Schmidt <der.eremit@email.de> wrote:

> On Sat, 21 Aug 2004 14:50:08 +0200, you wrote in linux.kernel:
>
> > If the owners and permissions of the filesystem have been set up correctly,
> > then there is no security problem. 
>
> The previous Linux implementation allowed users with *read* access
> to the device to send arbitrary SG_IO commands. Giving read permission

This is of course a kernel bug - but it could be easily fixed.
My scg driver for SunOS requires write permissions since it has been
created in August 1986.


> to normal users is quite common, to allow them to run isosize or play
> their freshly burned SVCDs with mplayer.

So changing the kernel to require write permissions would be a simple fix that
would help without breaking cdrtools as libscg of course opens the devices with 
O_RDWR.

I am not against a long term change that would require euid root too, but this 
should be announced early enough to allow prominent users of the interface to 
keep track of the interface changes.

BTW: the currely used errno EACCESS applies to file permissions while EPERM
applies to process permissions. So EPERM would be a more appropriate errno 
value.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Pascal Schmidt]

On Sat, 21 Aug 2004, Joerg Schilling wrote:

> So changing the kernel to require write permissions would be a simple
> fix that would help without breaking cdrtools as libscg of course opens
> the devices with O_RDWR.

I agree, but Linus obviously thought otherwise. Reverting that and
doing the above fix instead would create three different behaviours
for different 2.6.x kernel versions, which is also undesirable.

> I am not against a long term change that would require euid root too,
> but this should be announced early enough to allow prominent users of
> the interface to keep track of the interface changes.

Too late for that now, no matter whether we like it or not... however,
at least the discussion now has shown that changes to this interface
need to be considered carefully, so maybe the future will be
bright. ;)

-- 
Ciao,
Pascal

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Let me give some additional remarks to clear up things:

Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:

> Pascal Schmidt <der.eremit@email.de> wrote:

> > The previous Linux implementation allowed users with *read* access
> > to the device to send arbitrary SG_IO commands. Giving read permission
>
> This is of course a kernel bug - but it could be easily fixed.
> My scg driver for SunOS requires write permissions since it has been
> created in August 1986.

Not checking for Write access permissions at this place is a typical mistake
made by novice programmers, so I never thought this could be in Linux.....


> > to normal users is quite common, to allow them to run isosize or play
> > their freshly burned SVCDs with mplayer.
>
> So changing the kernel to require write permissions would be a simple fix that
> would help without breaking cdrtools as libscg of course opens the devices with 
> O_RDWR.

If Linux still noes not check for write permissions, I would consider there is 
still a bug.

If there is a list of "aparently safe" SCSI commands that are allowed to be 
executed, then there is another bug in Linux. The only SCSI command that could 
be called safe if Test Unit Ready and even this only if not send more then once 
every few seconds.

There are several SCSI commands that look safe but would result in coasters
if issued while a CD or DVD is written.

Conclusion: It makes no sense to start implementing a fine grained security 
model before basic secutity has been done correctly.

The best immediate fix for the problem is to just check for read & write 
permissions on the file descriptor and otherwise revert to how it has been
before 2.6.8.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

> > Pascal Schmidt <der.eremit@email.de> wrote:

>> I am not against a long term change that would require euid root too,
>> but this should be announced early enough to allow prominent users of
>> the interface to keep track of the interface changes.

>Too late for that now, no matter whether we like it or not... however,
>at least the discussion now has shown that changes to this interface
>need to be considered carefully, so maybe the future will be
>bright. ;)

Eveybody makes mistakes. Not being able to admid that and persisting to 
continue to go in a wrong direction is the real problem.

There is no problem to do what I did propose.

And the wrong decision could have even be avoided if people did contact me
before they did act....


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Patrick McFarland]

On Sun, 22 Aug 2004 14:14:08 +0200, Joerg Schilling
<schilling@fokus.fraunhofer.de> wrote:
> Eveybody makes mistakes. Not being able to admid that and persisting to
> continue to go in a wrong direction is the real problem.
 
Yes, everyone does. Yours was flaming kernel developers over the lkml
about bugs in your own program; yet, you do not admit to this, and
continue to piss everyone off.

-- 
Patrick "Diablo-D3" McFarland || diablod3@gmail.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Patrick McFarland <diablod3@gmail.com> wrote:

> On Sun, 22 Aug 2004 14:14:08 +0200, Joerg Schilling
> <schilling@fokus.fraunhofer.de> wrote:
> > Eveybody makes mistakes. Not being able to admid that and persisting to
> > continue to go in a wrong direction is the real problem.
>  
> Yes, everyone does. Yours was flaming kernel developers over the lkml
> about bugs in your own program; yet, you do not admit to this, and
> continue to piss everyone off.

You seem to be unable to distinct between cause and effect.

	Some pleople at Linux kernel ML did start to flame me while I was
	trying to do my best to give technical based explanations.

As it has been proven that threre _are_ reasonable people in LKML, it would 
help LKML to regain credibility if they could try to do some self cleaning
and find a way to calm down the non-serious people.


You also seem to be unable to judge where bugs are located while looking at 
problems.

	It seems that we just agreed with the reasonable members of LKML
	that there was and still is a security related bug in Linux.
	The "fix" that used in hope to remove the security problems did just
	create new problems instead of removing old ones.

If you have nothing useful to say, please stay quiet.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Horst von Brand]

Joerg Schilling <schilling@fokus.fraunhofer.de> said:
> Patrick McFarland <diablod3@gmail.com> wrote:
> > On Sun, 22 Aug 2004 14:14:08 +0200, Joerg Schilling
> > <schilling@fokus.fraunhofer.de> wrote:
> > > Eveybody makes mistakes. Not being able to admid that and persisting to
> > > continue to go in a wrong direction is the real problem.
> >  
> > Yes, everyone does. Yours was flaming kernel developers over the lkml
> > about bugs in your own program; yet, you do not admit to this, and
> > continue to piss everyone off.
> 
> You seem to be unable to distinct between cause and effect.

Exactly right.

> 	Some pleople at Linux kernel ML did start to flame me while I was
> 	trying to do my best to give technical based explanations.
> 
> As it has been proven that threre _are_ reasonable people in LKML, it would 
> help LKML to regain credibility if they could try to do some self cleaning
> and find a way to calm down the non-serious people.

Bann you from the list would go a long way, true; but I oppose such
measures as a matter of principle. Better try to convince the people
out-of-line to do their own soul searching. Hasn't worked so far, sadly.

> You also seem to be unable to judge where bugs are located while looking at 
> problems.
> 
> 	It seems that we just agreed with the reasonable members of LKML
> 	that there was and still is a security related bug in Linux.
> 	The "fix" that used in hope to remove the security problems did just
> 	create new problems instead of removing old ones.
> 
> If you have nothing useful to say, please stay quiet.

There was a security problem, I think all agree on that. LKML says any
security problem has to be fixed ASAP, especially if it is well known and
easy to exploit. You say backward compatibility is more important. The
people in charge of the kernel are the ones who decide what to do, in this
case they overwhelmingly decided against you. Though luck.

[Yes, I fully expect you to tell me this is not useful. Perhaps it isn't.
 But continuing to pour gas on the flames (as you are so fond doing)
 doesn't help either.]
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Horst von Brand]

Joerg Schilling <schilling@fokus.fraunhofer.de> said:

[...]

> And the wrong decision could have even be avoided if people did contact me
> before they did act....

Exactly! They should also contact me and ask politely each time they
consider a change if I'd allow it. Really. The nerve these guys have.
Unbelievable.

In the end, I'd only say that I've been on LKML for a long, long time
(since it started, more or less). And each single time the head hackers
agreed on something, and there was a single dissenter, the dissenter was in
the wrong. Sure, this time could be different, but I have seen absolutely
no (yes, _no_) evidence here to the contrary.

The kernel changed, badly conceived interfases were (somewhat, perhaps
broken in another way) fixed. Some applications that depended on the
brokenness don't work now. Tough luck, fix the applications and
(optionally) ask _politely_, with _detailed discussion_, perhaps propose a
better fix for the kernel. Just whining that the application broke during
its "code freeze" won't get you anywhere (you just can't expect to hold the
kernel hostage to your random, mostly unrelated, program's development
schedule; that model just won't get anywhere real fast). 

Treating everybody as ignorant morons isn't exactly the best way to be
heard. And in this case there is ample evidence on hand that they are very
smart people who usually are right in regards to the techical matters they
have in their hands.

I.e., you are making a fool of yourself here.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Matthias Andree]

On Sun, 22 Aug 2004, Horst von Brand wrote:

> In the end, I'd only say that I've been on LKML for a long, long time
> (since it started, more or less). And each single time the head hackers
> agreed on something, and there was a single dissenter, the dissenter was in
> the wrong. Sure, this time could be different, but I have seen absolutely
> no (yes, _no_) evidence here to the contrary.

There _are_ cases where a kernel patch sneaked to a subsystem maintainer
has made it even when some of the "heads" said it was impossible.

The key is convincing a subsystem maintainer that the patch helps and
doesn't hurt. And that doesn't work with a rant and can sometime take a
kernel patch to show how it works.  A decent patch with a more decent
description works wonders - usually.

-- 
Matthias Andree

NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF!
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Pascal Schmidt]

On Sun, 22 Aug 2004, Joerg Schilling wrote:

> Not checking for Write access permissions at this place is a typical
> mistake made by novice programmers, so I never thought this could be in
> Linux.....

People will find this kind of language inflammatory. ;) However, exactly
because it is such a bad mistake did Linus put out what he deemed a
correct fix *immediately*.

> If Linux still noes not check for write permissions, I would consider
> there is still a bug.

The open question is whether write permission really is meaningful
enough to allow arbitrary SCSI commands. I personally think "being
able to wipe the drive firmware" is too much, and since filtering
of vendor commands is generally impossible to do right, sending SG_IO
should require CAP_SYS_RAWIO capability.

> If there is a list of "aparently safe" SCSI commands that are allowed to
> be executed, then there is another bug in Linux. The only SCSI command
> that could be called safe if Test Unit Ready and even this only if not
> send more then once every few seconds.

Currently (2.6.8.1), there is a list in the kernel. I agree that it
doesn't make sense. I would think read permission means to be able
to read from the device, write means you can write. I would even go
as far as *not* to have that mean "you can also read/write via SG_IO",
because for normal uses of the device, read(2) and write(2) should be
enough.

BTW, there are a number of people on the kernel list who believe a
filter list is bad and generally unmaintainable.

> There are several SCSI commands that look safe but would result in coasters
> if issued while a CD or DVD is written.

Good point.

> The best immediate fix for the problem is to just check for read & write
> permissions on the file descriptor and otherwise revert to how it has been
> before 2.6.8.

I don't think that's going to happen. You already said you'd be okay
with euid==0 being required for burning, if only the transition
period were longer. So if people complain to you that cdrecord is
broken with 2.6.8, you will have to tell them burning requires root
for the moment. Then in your next release, change your startup
code not to drop the CAP_SYS_RAWIO capability when you drop root
privileges.

Alternatively, provide a patch that changes the current code to just
require write permission or CAP_SYS_RAWIO to be able to send
arbitrary commands. Then, after a transition period, submit a patch
that changes it to just CAP_SYS_RAWIO. The patch would look like the
one below (untested).

Jens, since this seems to be your code, what do you think?


--- scsi_ioctl.c	2004-08-14 18:26:17.000000000 +0200
+++ scsi_ioctl.c.new	2004-08-22 15:08:36.000000000 +0200
@@ -105,70 +105,12 @@ static int sg_emulated_host(request_queu
 	return put_user(1, p);
 }

-#define CMD_READ_SAFE	0x01
-#define CMD_WRITE_SAFE	0x02
-#define safe_for_read(cmd)	[cmd] = CMD_READ_SAFE
-#define safe_for_write(cmd)	[cmd] = CMD_WRITE_SAFE
-
-static int verify_command(struct file *file, unsigned char *cmd)
+static int verify_command(struct file *file)
 {
-	static const unsigned char cmd_type[256] = {
-
-		/* Basic read-only commands */
-		safe_for_read(TEST_UNIT_READY),
-		safe_for_read(REQUEST_SENSE),
-		safe_for_read(READ_6),
-		safe_for_read(READ_10),
-		safe_for_read(READ_12),
-		safe_for_read(READ_16),
-		safe_for_read(READ_BUFFER),
-		safe_for_read(READ_LONG),
-		safe_for_read(INQUIRY),
-		safe_for_read(MODE_SENSE),
-		safe_for_read(MODE_SENSE_10),
-		safe_for_read(START_STOP),
-
-		/* Audio CD commands */
-		safe_for_read(GPCMD_PLAY_CD),
-		safe_for_read(GPCMD_PLAY_AUDIO_10),
-		safe_for_read(GPCMD_PLAY_AUDIO_MSF),
-		safe_for_read(GPCMD_PLAY_AUDIO_TI),
-
-		/* CD/DVD data reading */
-		safe_for_read(GPCMD_READ_CD),
-		safe_for_read(GPCMD_READ_CD_MSF),
-		safe_for_read(GPCMD_READ_DISC_INFO),
-		safe_for_read(GPCMD_READ_CDVD_CAPACITY),
-		safe_for_read(GPCMD_READ_DVD_STRUCTURE),
-		safe_for_read(GPCMD_READ_HEADER),
-		safe_for_read(GPCMD_READ_TRACK_RZONE_INFO),
-		safe_for_read(GPCMD_READ_SUBCHANNEL),
-		safe_for_read(GPCMD_READ_TOC_PMA_ATIP),
-		safe_for_read(GPCMD_REPORT_KEY),
-		safe_for_read(GPCMD_SCAN),
-
-		/* Basic writing commands */
-		safe_for_write(WRITE_6),
-		safe_for_write(WRITE_10),
-		safe_for_write(WRITE_VERIFY),
-		safe_for_write(WRITE_12),
-		safe_for_write(WRITE_VERIFY_12),
-		safe_for_write(WRITE_16),
-		safe_for_write(WRITE_BUFFER),
-		safe_for_write(WRITE_LONG),
-	};
-	unsigned char type = cmd_type[cmd[0]];
-
-	/* Anybody who can open the device can do a read-safe command */
-	if (type & CMD_READ_SAFE)
+	/* write access means being able to send any command (for now) */
+	if (file->f_mode & FMODE_WRITE)
 		return 0;

-	/* Write-safe commands just require a writable open.. */
-	if (type & CMD_WRITE_SAFE) {
-		if (file->f_mode & FMODE_WRITE)
-			return 0;
-	}
-
 	/* And root can do any command.. */
 	if (capable(CAP_SYS_RAWIO))
 		return 0;
@@ -181,7 +123,7 @@ static int sg_io(struct file *file, requ
 		struct gendisk *bd_disk, struct sg_io_hdr *hdr)
 {
 	unsigned long start_time;
-	int reading, writing;
+	int reading, writing, res;
 	struct request *rq;
 	struct bio *bio;
 	char sense[SCSI_SENSE_BUFFERSIZE];
@@ -193,8 +135,8 @@ static int sg_io(struct file *file, requ
 		return -EINVAL;
 	if (copy_from_user(cmd, hdr->cmdp, hdr->cmd_len))
 		return -EFAULT;
-	if (verify_command(file, cmd))
-		return -EPERM;
+	if (res = verify_command(file))
+		return res;

 	/*
 	 * we'll do that later

-- 
Ciao,
Pascal

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Christer Weinigel]

Pascal Schmidt <der.eremit@email.de> writes:

> I would even go as far as *not* to have that mean "you can also
> read/write via SG_IO", because for normal uses of the device,
> read(2) and write(2) should be enough.

Ripping a CD is in my opinion a normal use of a CD.

> On Sun, 22 Aug 2004, Joerg Schilling wrote:
> > There are several SCSI commands that look safe but would result in coasters
> > if issued while a CD or DVD is written.
> 
> Good point.

Not really, if I have write permisson to a CD burner, being able to
burn a coaster by issuing strange commands is something I expect.
Being able to destroy the firmware of the drive is not something I
expect a normal user to be able to do.

There are at least three conflicting goals here:

1. Only someone with CAP_SYS_RAWIO (i.e. root) should be able to do
   possible destructive things to a device, and only root should be
   able to bypass the normal security checks in the kernel (e.g. get
   access to /dev/mem since access to it means that you can read and
   modify internal kernel structures).

2. A Linux system should have as few suid root binaries as possible.

3. A normal user should be able to perform most tasks without needing
   root.

As you said, since the old kernel behaviour is a gaping security hole,
Linus had no other choice than to add a CAP_SYS_RAWIO check to the
SG_IO call.  This fulfills goal 1.  Unfortunately it breaks just about
every application that expects to be able to send raw SCSI commands
without being root.

There are a couple of ways of fulfilling goal 3 and allow normal users
to burn a CDR:

One is to make cdrecord suid root and then make it drop all
capabilities except for SYS_CAP_RAWIO.  But even if cdrecord is
audited, there are a lot of other applications that need to be able to
send raw SCSI commands such as mt (to change the compression or tape
format of a streamer).  And this violates goal 2, every security guide
I've seen lately recommends minimizing the amount of suid binaries,
not adding more.

Another way is to add specialized ioctls in the kernel for everything,
such as the CDROMPLAYTRKIND to play a track.  Unfortunately, this gets
a bit unmaintainable with all the different devices out there.  It
would be akin to putting the whole of cdrecord into the kernel.

Yet another way is to try to filter the raw SCSI commands and only
allow through "known safe" commands, which is what some other people
have been trying to do.  

I think Joerg is being much too harsh, adding a check for
CAP_SYS_RAWIO fixes a bloody large security hole.  It broke a few
applications, but tough shit, that is what happens every now and then
when plugging security holes.  It would be much worse to leave the
hole open.  The timing may coincide badly with the release cycle of
cdrecord, but thats life.  For now users will have to run cdrecord as
root to be able to burn a CDR.

In the future, add a patch to cdrecord so that it can be run as suid
root and not drop CAP_SYS_RAWIO which will make most users happy.
It's still a violation of goal 2 but one has to do tradeoffs every now
and then.

For the future, well, I'm not sure, but personally I think that the
filter idea is a pretty good one.  It is a coarse sieve, but by
listing some "known safe" commands most applications should work, and
if somebody needs to send a command that isn't considered as safe yet,
he can just run the application as root instead.

In my opinion, the best way forward would be to only have a
CAP_SYS_RAWIO check in the kernel and an installable command filter
that can be configured from userspace.  So when the next version of
snazzycdwriter(tm) is released it can have a line in the README file
saying:

    If you want to be able to run snazzycdwriter(tm) as a normal user,
    add the following command to your rc.local file:

        /sbin/install-scsi-filter /dev/hdc snazzycdwriter.filter

And if you have a tape drive, it could have another list of safe
commands.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Christer Weinigel <christer@weinigel.se> wrote:

> Pascal Schmidt <der.eremit@email.de> writes:
>
> > I would even go as far as *not* to have that mean "you can also
> > read/write via SG_IO", because for normal uses of the device,
> > read(2) and write(2) should be enough.
>
> Ripping a CD is in my opinion a normal use of a CD.

But in order to rip an audio CD, you need to use e.g. MODE SELECT.
If you start to distinct safe SCSI commands from possibly unsafe ones, then 
MODE SELECT could not be in the list of safe ones.

> > On Sun, 22 Aug 2004, Joerg Schilling wrote:
> > > There are several SCSI commands that look safe but would result in coasters
> > > if issued while a CD or DVD is written.
> > 
> > Good point.
>
> Not really, if I have write permisson to a CD burner, being able to
> burn a coaster by issuing strange commands is something I expect.
> Being able to destroy the firmware of the drive is not something I
> expect a normal user to be able to do.

At SCSI level, there is no real difference.


> There are at least three conflicting goals here:
>
> 1. Only someone with CAP_SYS_RAWIO (i.e. root) should be able to do
>    possible destructive things to a device, and only root should be
>    able to bypass the normal security checks in the kernel (e.g. get
>    access to /dev/mem since access to it means that you can read and
>    modify internal kernel structures).

A powerful CD/DVD recording program needs to sometimes issue "secret"
and vendor unique SCSI commands in order to give nice features.

On a Plextor drive, you need to be able to issue a vendor unique SCSI command
to know the recommended write speed for a specific medium. A SCSI command
from same list of vendor unique commands allows you to tell the drive to read
any medium at 52x. This could destroy the medium _and_ the drive.

As you see: you cannot have the needed knowledge inside the kernel.


> 2. A Linux system should have as few suid root binaries as possible.

If you like this completely, you would need to implement something RBAC and
getppriv(2)(setpiriv(2) on Solaris. If you have this, you have zero suid
root binaries on a 'Trusted OS' and one suid binary (/usr/bin/pfexec) on a non 
Trusted system.

> 3. A normal user should be able to perform most tasks without needing
>    root.

Duable if my remark to 2) has been implemented.

> As you said, since the old kernel behaviour is a gaping security hole,
> Linus had no other choice than to add a CAP_SYS_RAWIO check to the
> SG_IO call.  This fulfills goal 1.  Unfortunately it breaks just about

Not true: a simple check like in my scg driver:

        /* 
         * Must have read/write access to /dev/scgxx 
         * to send commands over SCSI Bus. 
         */ 
        if ((flag&(FREAD|FWRITE)) != (FREAD|FWRITE)) 
                return (EACCES); 

was sudfficient.

> every application that expects to be able to send raw SCSI commands
> without being root.
>
> There are a couple of ways of fulfilling goal 3 and allow normal users
> to burn a CDR:
>
> One is to make cdrecord suid root and then make it drop all
> capabilities except for SYS_CAP_RAWIO.  But even if cdrecord is
> audited, there are a lot of other applications that need to be able to
> send raw SCSI commands such as mt (to change the compression or tape
> format of a streamer).  And this violates goal 2, every security guide
> I've seen lately recommends minimizing the amount of suid binaries,
> not adding more.

A better way is to have services like this in /usr/bin/pfexec that 
do the ecirity related parts before calling the other binaries.

BTW: 'mt' should not need to send SCSI comands. THis shoul dbe handled via
specilized ioctls.


> I think Joerg is being much too harsh, adding a check for
> CAP_SYS_RAWIO fixes a bloody large security hole.  It broke a few
> applications, but tough shit, that is what happens every now and then

With checking for ((flag&(FREAD|FWRITE)) != (FREAD|FWRITE)) less applications
would break.

> when plugging security holes.  It would be much worse to leave the
> hole open.  The timing may coincide badly with the release cycle of
> cdrecord, but thats life.  For now users will have to run cdrecord as
> root to be able to burn a CDR.

The result will be that users "find solutions" that will be less secure as
when only a check for ((flag&(FREAD|FWRITE)) != (FREAD|FWRITE)) has been 
introduced and _later_ (in an agreement with prominent applications)
require root when issuing SCSI commands.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Christer Weinigel]

Joerg Schilling <schilling@fokus.fraunhofer.de> writes:
> But in order to rip an audio CD, you need to use e.g. MODE SELECT.
> If you start to distinct safe SCSI commands from possibly unsafe ones, then 
> MODE SELECT could not be in the list of safe ones.

Yes, I'm quite aware of that.  

So a filter would have to be smarter than just checking the command
codes.  There would have to be a special case for the mode page
commands which filters on accessible mode pages.

Are there any other commands that would need filtering at a finer
grain than the command level?

Additionally, another thing that is really needed is to match
the different variants of hdr->dxfer_direction against the direction
of the commands, otherwise one could ask for a REQUEST_SENSE but with
a direction of SG_DXFER_TO_DEV.  This isn't a security problem in the
sense that it can destroy the drive itself, but it might hang the
IDE state machine in the kernel, motherboard or drive.  

> > Not really, if I have write permisson to a CD burner, being able to
> > burn a coaster by issuing strange commands is something I expect.
> > Being able to destroy the firmware of the drive is not something I
> > expect a normal user to be able to do.
> 
> At SCSI level, there is no real difference.

SG_IO does not have to work at the SCSI level, it can filter the
commands at a higher level.

> A powerful CD/DVD recording program needs to sometimes issue "secret"
> and vendor unique SCSI commands in order to give nice features.
> 
> On a Plextor drive, you need to be able to issue a vendor unique SCSI command
> to know the recommended write speed for a specific medium. A SCSI command
> from same list of vendor unique commands allows you to tell the drive to read
> any medium at 52x. This could destroy the medium _and_ the drive.
> 
> As you see: you cannot have the needed knowledge inside the kernel.

So guess why I suggested that the kernel should contain the mechanics
to filter commands (and yes, I was aware of the mode page problems but
didn't want to make a long mail even longer), and that the list of
commands would be uploaded to the kernel from userspace.  It was at
the end of the mail you replied to...

That way an application, such as cdrecord, could keep a list of safe
commands for each device and use the appropriate list for each kind of
device.  If the device is a tape, allow access to the mode page that
can control BPI and compression settings.  If it's a cdrom, allow
access to the mode page with CDDA settings.

Of course, if it isn't possible to do this at a mode page level, maybe
the access controls would have to be at the level of individual bits
in a mode page, then it gets trickier.  It might, or might not be
feasible to implement such a filte.  I don't know which is true or
which is not, I'm just trying to look at ways of solving the problem.

> > 2. A Linux system should have as few suid root binaries as possible.
> 
> If you like this completely, you would need to implement something RBAC and
> getppriv(2)(setpiriv(2) on Solaris. If you have this, you have zero suid
> root binaries on a 'Trusted OS' and one suid binary (/usr/bin/pfexec) on a non 
> Trusted system.

Which is not all that different from suid binaries.  Instead of
trusting an application, you're trusting a user or a role.  This isn't
much different from giving "trusted" users access to /dev/scd0.  

> > As you said, since the old kernel behaviour is a gaping security hole,
> > Linus had no other choice than to add a CAP_SYS_RAWIO check to the
> > SG_IO call.  This fulfills goal 1.  Unfortunately it breaks just about
> 
> Not true: a simple check like in my scg driver:
> 
>         /* 
>          * Must have read/write access to /dev/scgxx 
>          * to send commands over SCSI Bus. 
>          */ 
>         if ((flag&(FREAD|FWRITE)) != (FREAD|FWRITE)) 
>                 return (EACCES); 
>
> was sudfficient.

No.  Sure, you can redefine read access to a SCSI device to mean "may
only use normal read" and write access to "may use read, write and
send raw SCSI commands", but that is a rather bad fit to how
read/write normally are used.

What do you do if you want to allow users with read access to
read a SCSI tape (and to be able select the BPI)?  With your
suggestion, the user will need write access too, but I may just want
to give the user read access.

> BTW: 'mt' should not need to send SCSI comands. THis shoul dbe handled via
> specilized ioctls.

So why can't cdrecord use specialized ioctls then?

> With checking for ((flag&(FREAD|FWRITE)) != (FREAD|FWRITE)) less applications
> would break.

cdrecord probably wouldn't break.  Other applications that open
/dev/scd0 as readonly would break.  cdrecord isn't the only
application in the world you know.

The Linux philosophy is "do it right".  And when Linus has been
changing interfaces he has said that he prefers something to break
noisily (not compile) rather than to get compile fixes that leave the
bugs still in there.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

Re: DTrace-like analysis possible with future Linux kernels?

[Joerg Schilling]

Julien Oster wrote:

>> http://www.theregister.co.uk/2004/07/08/dtrace_user_take/:
>> "Sun sees DTrace as a big advantage for Solaris over other versions of Unix 
>> and Linux."

>That article is way too hypey.

The article is ay too pessimisctic compared to the real possibilities that 
Dtrace offers.


>The same applies to that article, I couldn't even read it completely,
>it was just too much.

If you did not read it completely, how cah you judge about it?

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Giuseppe Bilotta]

Joerg Schilling wrote:
> A powerful CD/DVD recording program needs to sometimes issue "secret"
> and vendor unique SCSI commands in order to give nice features.
> 
> On a Plextor drive, you need to be able to issue a vendor unique SCSI command
> to know the recommended write speed for a specific medium. A SCSI command
> from same list of vendor unique commands allows you to tell the drive to read
> any medium at 52x. This could destroy the medium _and_ the drive.
> 
> As you see: you cannot have the needed knowledge inside the kernel.

Actually I was wondering about this exactly: why shouldn't this 
knowledge be built into the kernel? IMO it should be. Isn't the 
kernel purpose to do that, among other things? HAL?

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Julien Oster]

Joerg Schilling <schilling@fokus.fraunhofer.de> writes:

> But in order to rip an audio CD, you need to use e.g. MODE SELECT.
> If you start to distinct safe SCSI commands from possibly unsafe ones, then 
> MODE SELECT could not be in the list of safe ones.

That is why I'm proposing an empty filter at boot time, which allows
no SG_IO except when having CAP_SYS_RAWIO (which enables everything)
and the possibility to open up certain commands from userspace later.

Julien

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Julien Oster <lkml-7994@mc.frodoid.org> wrote:

> Joerg Schilling <schilling@fokus.fraunhofer.de> writes:
>
> > But in order to rip an audio CD, you need to use e.g. MODE SELECT.
> > If you start to distinct safe SCSI commands from possibly unsafe ones, then 
> > MODE SELECT could not be in the list of safe ones.
>
> That is why I'm proposing an empty filter at boot time, which allows
> no SG_IO except when having CAP_SYS_RAWIO (which enables everything)
> and the possibility to open up certain commands from userspace later.

If the related /dev/* nodes are owned by root and set up rw-r-r or worse 
for others and requiring write access to send SCSI commands, then you get
the same kind of authentification, but cdrecord would continue to work.

Only if someone would chown the related /dev/* nodes to a user differen from 
root there would be a difference.

P.S.: UNIX philosohy is to allow the administrator to set up bad/wrong permissions.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Matthias Andree]

Joerg Schilling schrieb am 2004-08-23:

> Only if someone would chown the related /dev/* nodes to a user differen from 
> root there would be a difference.

...which actually happens a lot, with the devperm PAM junk that some,
particularly desktop/end-user oriented distros do, for instance SuSE
Linux twist device permissions. It is awful for shared computers in a
network.

-- 
Matthias Andree

NOTE YOU WILL NOT RECEIVE MY MAIL IF YOU'RE USING SPF!
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Kai Makisara]

On Sun, 22 Aug 2004, Joerg Schilling wrote:

> Christer Weinigel <christer@weinigel.se> wrote:
> 
...
> > One is to make cdrecord suid root and then make it drop all
> > capabilities except for SYS_CAP_RAWIO.  But even if cdrecord is
> > audited, there are a lot of other applications that need to be able to
> > send raw SCSI commands such as mt (to change the compression or tape
> > format of a streamer).  And this violates goal 2, every security guide
> > I've seen lately recommends minimizing the amount of suid binaries,
> > not adding more.
> 
> A better way is to have services like this in /usr/bin/pfexec that 
> do the ecirity related parts before calling the other binaries.
> 
> BTW: 'mt' should not need to send SCSI comands. THis shoul dbe handled via
> specilized ioctls.
> 
There are already ioctls for changing the tape parameters. Christer, there 
is no need to introduce tapes into this discussion.

-- 
Kai

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Christer Weinigel]

Kai Makisara <Kai.Makisara@kolumbus.fi> writes:

> On Sun, 22 Aug 2004, Joerg Schilling wrote:
> 
> > Christer Weinigel <christer@weinigel.se> wrote:
> > BTW: 'mt' should not need to send SCSI comands. THis shoul dbe handled via
> > specilized ioctls.
> > 
> There are already ioctls for changing the tape parameters. Christer, there 
> is no need to introduce tapes into this discussion.

It was en example of another application that needs to modify the mode
pages, and it's interesting to look at how we have solved similar
problems before.

So if we want to be consistent we ought to introduce specialized
ioctls for everything cdrecord wants to do.  Otoh, tape drives don't
seem to be such a fast moving target as CD and DVD burners.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Joerg Schilling]

Kai Makisara <Kai.Makisara@kolumbus.fi> wrote:

> > BTW: 'mt' should not need to send SCSI comands. THis shoul dbe handled via
> > specilized ioctls.
> > 
> There are already ioctls for changing the tape parameters. Christer, there 
> is no need to introduce tapes into this discussion.

This is my words....


Tape drives have a well known and simple and standardized interface since many
years (> 40). There exist ioctl()s to do anything you like.


CD/DVD writing ist still constantly evolving, so you cannot have it in the 
kernel.

BTW: I am strongly against any list of "safe commands" as this would only make 
things more complicated. Things that control security should be ket simple.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Christer Weinigel]

/me keeping to the bad habit of following up to myself

Regarding the current 2.6.8 kernel, wouldn't it be a better idea to
move the CAP_SYS_RAWIO check to open time instead of when the ioctl is
called?  This would require a new flag somewhere in the file structure
I suppose, e.g. file->f_mode & FMODE_RAWIO.  

That would allow a suid root application to open the cdrom and then
drop all capabilities including RAWIO and would probably fit better
into how cdrecord expects things to work.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Alan Cox]

On Sul, 2004-08-22 at 17:33, Christer Weinigel wrote:
> /me keeping to the bad habit of following up to myself
> 
> Regarding the current 2.6.8 kernel, wouldn't it be a better idea to
> move the CAP_SYS_RAWIO check to open time instead of when the ioctl is
> called?  This would require a new flag somewhere in the file structure
> I suppose, e.g. file->f_mode & FMODE_RAWIO.  

This leads to all sorts of bugs where descriptors owned by one process
are given to another less priviledged one. In the networking world
similar logic led to holes because rsh for example gave root opened fd's
to users.

Alan

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Christer Weinigel]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> On Sul, 2004-08-22 at 17:33, Christer Weinigel wrote:
> > Regarding the current 2.6.8 kernel, wouldn't it be a better idea to
> > move the CAP_SYS_RAWIO check to open time instead of when the ioctl is
> > called?  This would require a new flag somewhere in the file structure
> > I suppose, e.g. file->f_mode & FMODE_RAWIO.  
> 
> This leads to all sorts of bugs where descriptors owned by one process
> are given to another less priviledged one. In the networking world
> similar logic led to holes because rsh for example gave root opened fd's
> to users.

On the other hand a bug in my favourite cd burner application could
give away SYS_CAP_RAWIO instead, and I think that is even worse.

Besides, checking SYS_CAP_RAWIO at open time is the way /dev/mem
works.  OTOH applications don't normally hand over /dev/mem to other
applications I suppose.  

I'm just tossing ideas around, please ignore me if they are stuipd :-)

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Alan Cox]

On Sul, 2004-08-22 at 18:31, Christer Weinigel wrote:
> On the other hand a bug in my favourite cd burner application could
> give away SYS_CAP_RAWIO instead, and I think that is even worse.

Its not an easy trade off- I don't know if there is a right answer.
Despite the UI problems in both cdrecord and its author the internal
code is actually quite rigorous so its something I'd be more comfortable
giving limited rawio access than quite a few other apps that touch
external public data.

Alan

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Christer Weinigel]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> Its not an easy trade off- I don't know if there is a right answer.
> Despite the UI problems in both cdrecord and its author the internal
> code is actually quite rigorous so its something I'd be more comfortable
> giving limited rawio access than quite a few other apps that touch
> external public data.

Another way would be to add a scsi ioctl such as ENABLE_SG_IO or an
open flag, e.g. open("/dev/hdc", ... | O_RAWIO) which needs
CAP_SYS_RAWIO.  That way it is much less likely that the RAWIO
permission is given away by mistake, but I must admit that it feels
kind of ugly.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Adam Sampson]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

>> Regarding the current 2.6.8 kernel, wouldn't it be a better idea to
>> move the CAP_SYS_RAWIO check to open time instead of when the ioctl is
>> called?
> This leads to all sorts of bugs where descriptors owned by one process
> are given to another less priviledged one.

Yes, but that's a class of bugs that are pretty well understood these
days; handing privileged FDs around is a moderately common and
pleasantly fine-grained way of doing things. Closing an FD is at least
as easy as dropping a capability, which is what you'd have to do
with the current scheme upon entering unprivileged code.

Besides, setuid CD-recording tools already have to worry about closing
unsafe FDs when they drop privileges, so this doesn't seem to add any
new security holes...

Thanks,

-- 
Adam Sampson <azz@us-lot.org>                        <http://offog.org/>

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Tonnerre]

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

Salut,

On Sun, Aug 22, 2004 at 06:00:01PM +0200, Christer Weinigel wrote:
>     If you want to be able to run snazzycdwriter(tm) as a normal user,
>     add the following command to your rc.local file:
> 
>         /sbin/install-scsi-filter /dev/hdc snazzycdwriter.filter

Well, for that it might be  a nice feature to register and delete such
filters  online, using  a  register/remove_scsi_filter interface,  but
well, otoh that might be undesirable security-wise.

			    Tonnerre

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

Re: DTrace-like analysis possible with future Linux kernels?

[Joerg Schilling]

Alan Cox wrote:

>> In Solaris DTrace is enabled in _normal production_ kernel and you can 
>> hang any probe or probes set without restarting system or any runed
>> application which was compiled withoud debug info.
>
>Solaris only runs on large computers. You don't want kprobes randomly on
>your phone, pda, wireless router. Solaris deals with an extremely narrow
>market segment of "big computers for people with lots of money".
...
>> http://blogs.sun.com/roller/page/bmc/20040820#dtrace_on_lkml
>> Bryan blog is also yet another Dtrace knowledge source ..
>
>Coo I thought only the Sun CEO spent his life making inappropriate
>comments 8)

It seems that Alan does not like to miss a single day to degrade his 
credibiltiy :-(

A fact based discussion looks different...

-	What is a "large computer"?

-	What is an "extremely narrow market segment"?
	What is the evidence of this statement compared to Linux?

-	What are the minimum requirements for a machine to run Linux?

-	What are the minimum requirements for a machine to run Solaris?

People who cannot answer these questions should not try to start mad
speculations on derived conclusions.

The size of the loadable dtrace module is ~ 100 kB, this is nothing bad even 
for small appliances these days.

Guess what Brian Cantrill is running on his notebook?

Guess what machine Brian is using to run dtrace demos on shows?

And hey, Brian is even able to make a 4 hour demo within a single hour on this 
machine ;-)

Dtrace is a powerful idea that gives unbelievable new opportinities to 
developers, sysadmins and users. 


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: DTrace-like analysis possible with future Linux kernels?

[Tonnerre]

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

Salut,

On Sun, Aug 22, 2004 at 10:14:12PM +0200, Joerg Schilling wrote:
> -	What is a "large computer"?

I'd refer to a computer as a large computer when its calculation power
is several times  larger than the one home computers  of the same time
have (or if  it's a really large machine, such  as the Honeywell DDPs,
but that's another dimension of "large").

> -	What is an "extremely narrow market segment"?

A market  segment not  reaching waste portions  of all customers  in a
market. Think of catfood.

> 	What is the evidence of this statement compared to Linux?

Linux is  actually widely employed  in the home computer  *and* server
market,  plus embedded  devices.  I  mean, did  you  ever see  someone
running Solaris on their video decoder?

> -	What are the minimum requirements for a machine to run Linux?

Intel 8086  processor with  a few ko  of RAM,  with a floppy  drive, a
monitor and a floppy, I think. If you take only the normal kernel into
account that will be an 80386 processor.

> -	What are the minimum requirements for a machine to run Solaris?

At least more RAM and a more capable processor.

> And hey, Brian is even able to make a 4 hour demo within a single hour on this 
> machine ;-)

Greeeat. I can do that too on my Powerbook G5.

				Tonnerre

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

Re: DTrace-like analysis possible with future Linux kernels?

[Alan Cox]

On Sul, 2004-08-22 at 21:33, Tonnerre wrote:
> > -	What are the minimum requirements for a machine to run Linux?
> 
> Intel 8086  processor with  a few ko  of RAM,  with a floppy  drive, a
> monitor and a floppy, I think. If you take only the normal kernel into
> account that will be an 80386 processor.

Minimum for an x86 kernel is about 2Mb and 386 CPU. The 8086 subset
kernel isn't really "Linux", its more an escaped insanity. For non x86
you need a bottom end mmuless 32bit processor and a couple of Mb.

There are folks driving the size down (the -tiny patches) because
2Mb for the entire system is still too large for some users.

Alan

Re: DTrace-like analysis possible with future Linux kernels?

[Joerg Schilling]

Tonnerre <tonnerre@thundrix.ch> wrote:

> > -	What are the minimum requirements for a machine to run Linux?
>
> Intel 8086  processor with  a few ko  of RAM,  with a floppy  drive, a
> monitor and a floppy, I think. If you take only the normal kernel into
> account that will be an 80386 processor.

A few k ?????

> > -	What are the minimum requirements for a machine to run Solaris?
>
> At least more RAM and a more capable processor.

Looks like a speculation. 

> > And hey, Brian is even able to make a 4 hour demo within a single hour on this 
> > machine ;-)
>
> Greeeat. I can do that too on my Powerbook G5.

Can you do it by typing in _all_ commands and dtrace programs in real time?

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: DTrace-like analysis possible with future Linux kernels?

[Christer Weinigel]

Joerg Schilling <schilling@fokus.fraunhofer.de> writes:

> Tonnerre <tonnerre@thundrix.ch> wrote:
> 
> > > -	What are the minimum requirements for a machine to run Linux?
> >
> > Intel 8086  processor with  a few ko  of RAM,  with a floppy  drive, a
> > monitor and a floppy, I think. If you take only the normal kernel into
> > account that will be an 80386 processor.
> 
> A few k ?????

It depends on your definition of "a few k" :-)

    http://elks.sourceforge.net/

It will run fine on an 8086 with 512 kBytes of RAM, but I its possible
to get by with as little as 200kByte of RAM.

I work with embedded Linux systems and the standard configuration for
the stuff I do is with a small embedded processor such as the Motorola
MPC860 or the Axis Etrax 100 (about as fast as an i486) and 8MByte of
RAM and 4MByte of flash.  It's really no problem running in 2MByte of
RAM and 2MByte of flash but then the system really just does one thing
such as initializing a routing table and then routing data back and
forth.  To be able to get OpenSSL running in there and so on I really
need 8MByte of RAM.

> > > -	What are the minimum requirements for a machine to run Solaris?
> >
> > At least more RAM and a more capable processor.
> 
> Looks like a speculation. 

Well, I think Solaris is still supported on my SPARCclassic, but I
really really wouldn't like to try it with only 8MByte of RAM.  

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

Re: DTrace-like analysis possible with future Linux kernels?

[Joerg Schilling]

Christer Weinigel <christer@weinigel.se> wrote:

> It depends on your definition of "a few k" :-)
>
>     http://elks.sourceforge.net/
>
> It will run fine on an 8086 with 512 kBytes of RAM, but I its possible
> to get by with as little as 200kByte of RAM.

But this would not be a UNIX system... (see my other mail).

> I work with embedded Linux systems and the standard configuration for
> the stuff I do is with a small embedded processor such as the Motorola
> MPC860 or the Axis Etrax 100 (about as fast as an i486) and 8MByte of
> RAM and 4MByte of flash.  It's really no problem running in 2MByte of
> RAM and 2MByte of flash but then the system really just does one thing
> such as initializing a routing table and then routing data back and
> forth.  To be able to get OpenSSL running in there and so on I really
> need 8MByte of RAM.

If you don't try to run fancy stuff (like a GUI), I am sure that Solaris
will run with a machine that has something between 2 and 4 MB of RAM.

Note that if you design new embedded hardware, you typically think in
units of 16 MB.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: DTrace-like analysis possible with future Linux kernels?

[Horst von Brand]

Joerg Schilling <schilling@fokus.fraunhofer.de> said:
> Alan Cox wrote:
> 
> >> In Solaris DTrace is enabled in _normal production_ kernel and you can 
> >> hang any probe or probes set without restarting system or any runed
> >> application which was compiled withoud debug info.
> >
> >Solaris only runs on large computers. You don't want kprobes randomly on
> >your phone, pda, wireless router. Solaris deals with an extremely narrow
> >market segment of "big computers for people with lots of money".
> ...
> >> http://blogs.sun.com/roller/page/bmc/20040820#dtrace_on_lkml
> >> Bryan blog is also yet another Dtrace knowledge source ..
> >
> >Coo I thought only the Sun CEO spent his life making inappropriate
> >comments 8)
> 
> It seems that Alan does not like to miss a single day to degrade his 
> credibiltiy :-(

Strangely, it doesn't seem to affect his credibility at all. Yours, OTOH...

> A fact based discussion looks different...
> 
> -	What is a "large computer"?

Current Sun Enterprise. Typically several CPUs, several GiB RAM, connected
via fiber to TiB storage array.

> -	What is an "extremely narrow market segment"?

The one for the above machines. Duh...

> 	What is the evidence of this statement compared to Linux?

Millions of machines vs a few tens of thousands?

> -	What are the minimum requirements for a machine to run Linux?

Palm Pilot V or thereabouts.

> -	What are the minimum requirements for a machine to run Solaris?

Out of my league. My Sparc Ultra 1 can't. It is running Linux (Aurora)
quite happily, BTW.

> People who cannot answer these questions should not try to start mad
> speculations on derived conclusions.

Great! Does that mean you will /finally/ shut up?

PS: I do know for a fact that Alan did/does meddle with this kind of hardware.

> The size of the loadable dtrace module is ~ 100 kB, this is nothing bad even 
> for small appliances these days.

Add that, and a lot of other similarly small random junk, and we are soon
talking serious MiBs... Larry McVoy has made it very clear here that
Slowlaris got that bloated way one tiny, unnoticeable, not too relevant
feature at a time.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Bill Davidsen]

Tonnerre wrote:

> Well, for that it might be  a nice feature to register and delete such
> filters  online, using  a  register/remove_scsi_filter interface,  but
> well, otoh that might be undesirable security-wise.

Let me throw out two ideas to see if anyone find them useful.

1 - loadable command filters in the kernel.

Each device could have a filter set, which could be empty to require 
RAWIO capability, or set to a kernel default. Access could be made to 
modify a filter via proc, sysfs, or ioctl. The set method is not 
relevant to the idea.

2 - a filter program.

This one can be done right now, no kernel mod needed. A program with 
appropriate permissions can be started, and will create a command/status 
fifo pair with permissions which allow only programs with group 
permission to open. This allows the admin to put in any filter desired, 
know about vendor commands, etc. It also allows various security setups, 
the group can be on the user (trusted users) or on a setgid program 
(which limits the security issues).

Note that the permissions on individual devices need not be the same; I 
can have one group for disk, another for CD/DVD. You caould even be anal 
and have the filter time sensitive, etc.

A 'standard" place for the fifos helps portability, /var/sgio/dev/hda 
might be a directory, with fifos command and status.


Okay, did I miss something, or can this be solved without any additional 
kernel hacks?

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Doug Maxey]

On Mon, 23 Aug 2004 16:25:17 EDT, Bill Davidsen wrote:
>permission to open. This allows the admin to put in any filter desired,
> know about vendor commands, etc. It also allows various security
>setups,  the group can be on the user (trusted users) or on a setgid
>program  (which limits the security issues).

  Down such path lies madness :)   This list would have to be maintained for
  most every model, of every drive, for every manufacturer.  The list could
  conceivably change weekly, if not sooner.  This could change, of course, if
  the use of linux would become as ubiquitous as the dominant redmond produnt, 
  and the manufacturers would supply the "mini-port" driver bits, as it were.

  The theory is wonderful.  Until there is enough "clout" to change the 
  manufacturers participation, it is probably futile. :-/

++doug

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Bill Davidsen]

Doug Maxey wrote:
> On Mon, 23 Aug 2004 16:25:17 EDT, Bill Davidsen wrote:
> 
>>permission to open. This allows the admin to put in any filter desired,
>>know about vendor commands, etc. It also allows various security
>>setups,  the group can be on the user (trusted users) or on a setgid
>>program  (which limits the security issues).
> 
> 
>   Down such path lies madness :)   This list would have to be maintained for
>   most every model, of every drive, for every manufacturer.  The list could
>   conceivably change weekly, if not sooner.  This could change, of course, if
>   the use of linux would become as ubiquitous as the dominant redmond produnt, 
>   and the manufacturers would supply the "mini-port" driver bits, as it were.
> 
>   The theory is wonderful.  Until there is enough "clout" to change the 
>   manufacturers participation, it is probably futile. :-/

But you don't need magic vendor commands to read and write disk (or 
tape), you can do it with the base commands defined in SCSI-II. You only 
need filter lists for special cases where (a) you really do want vendor 
commands and (b) there's some reason to allow this to normal users.

I doubt that you need magic for any of the other obvious devices like 
SCSI scanners, ZIP and LS120 drives using ATA access rather than 
ide-floppy or ide-scsi, etc. I could be wrong on scanners, the setup 
commands may be more dangerous than I think.

To write CD unfortunately does seem to take more than I want the average 
user to do.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Nuno Silva]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

Bill Davidsen wrote:
| Tonnerre wrote:
|
|> Well, for that it might be  a nice feature to register and delete such
|> filters  online, using  a  register/remove_scsi_filter interface,  but
|> well, otoh that might be undesirable security-wise.
|
|
| Let me throw out two ideas to see if anyone find them useful.
|
| 1 - loadable command filters in the kernel.
|
| Each device could have a filter set, which could be empty to require
| RAWIO capability, or set to a kernel default. Access could be made to
| modify a filter via proc, sysfs, or ioctl. The set method is not
| relevant to the idea.
|
| 2 - a filter program.
|
| This one can be done right now, no kernel mod needed. A program with
| appropriate permissions can be started, and will create a command/status
| fifo pair with permissions which allow only programs with group
| permission to open. This allows the admin to put in any filter desired,
| know about vendor commands, etc. It also allows various security setups,
| the group can be on the user (trusted users) or on a setgid program
| (which limits the security issues).
|
| Note that the permissions on individual devices need not be the same; I
| can have one group for disk, another for CD/DVD. You caould even be anal
| and have the filter time sensitive, etc.
|
| A 'standard" place for the fifos helps portability, /var/sgio/dev/hda
| might be a directory, with fifos command and status.
|
|
| Okay, did I miss something, or can this be solved without any additional
| kernel hacks?

Sorry for jumping in this (hot) thread, but I just want to say something:

This is, IMHO, the way to go. Keeping static white-lists in the kernel
is bad and goes against the 2.6 moto: "do it in userspace".

Anyway, I can imagine that the distros are thinking about the problem
very hard. They can't just delete the cd-burn feature as non-root :-)

Also, many things can be affected by this, right? Scanners, jukeboxes,
ip-over-scsi, etc... A programmable kernel interface or a userspace
helper is the only way. To keep things _fast_, I'd be happy with a simple
# echo 1 > /sys/block/hdd/rawio/enable_rawio_if_user_can_write
brw-rw----  1 root disk 22, 64 Mar 14  2002 /dev/hdd
Now every member of @disk can trash your data and your cdrom's firmware.

If the admin sets this flag it's his responsability[*].

Peace,
Nuno Silva

[*] Once you start refusing to let root shoot himself in the foot
there's no way back. You must "fix" 60% of Linux! :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBKqZVOPig54MP17wRAgE0AJ9LjIKpK+S1nqBYYbOZywVontBdggCdGbF6
Uf2Ok3aFvCbXp6k4Wq7Pn2A=
=cEo2
-----END PGP SIGNATURE-----

(was: Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices)

[John Myers]

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

Christer Weinigel wrote:

> Pascal Schmidt <der.eremit@email.de> writes:

> [...] if I have write permisson to a CD burner, being able to
> burn a coaster by issuing strange commands is something I expect.
> Being able to destroy the firmware of the drive is not something I
> expect a normal user to be able to do.
> 
> There are at least three conflicting goals here:
> 
> 1. Only someone with CAP_SYS_RAWIO (i.e. root) should be able to do
>    possible destructive things to a device, and only root should be
>    able to bypass the normal security checks in the kernel (e.g. get
>    access to /dev/mem since access to it means that you can read and
>    modify internal kernel structures).
> 
> 2. A Linux system should have as few suid root binaries as possible.
> 
> 3. A normal user should be able to perform most tasks without needing
>    root.
> 

I hope this is not a stupid idea:

I propose a finer-grained approach to suid-root binaries. Perhaps, 
instead of having a single flag giving the binary all the rights and 
responsibilities of its owner, there could be a table/list/something of 
capabilities which we want to grant to the binary. This, of course, 
would be a privileged operation (perhaps a new capability?).

For example, we might want to grant cdrecord CAP_SYS_RAWIO. This way, we 
don't have to worry about cdrecord running as root and not dropping all 
the capabilities it doesn't need, by accident or by malice.

Further, and I realize that this would probably require major 
restructuring, perhaps there could be another field: for each capability 
we want to grant, a method to specify _where_ the binary can use that 
capability.

To extend the previous example: we might want to give cdrecord 
CAP_SYS_RAWIO just on, say, /dev/burner0 and /dev/burner1, but not 
/dev/hda. That way, some typo won't have us trying to burn cds with our 
hard disks.

Again, I hope it's not a stupid idea. I don't have a working 
implementation, and I'm not even sure if it's even possible, but it's a 
thought.
-- 
electronerd (jonathan s myers)
code poet and recycle bin monitor
programmer, monolith3d.com

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: (was: Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices)

[Joerg Schilling]

John Myers <electronerd@monolith3d.com> wrote:

> I hope this is not a stupid idea:
>
> I propose a finer-grained approach to suid-root binaries. Perhaps, 
> instead of having a single flag giving the binary all the rights and 
> responsibilities of its owner, there could be a table/list/something of 
> capabilities which we want to grant to the binary. This, of course, 
> would be a privileged operation (perhaps a new capability?).
>
> For example, we might want to grant cdrecord CAP_SYS_RAWIO. This way, we 
> don't have to worry about cdrecord running as root and not dropping all 
> the capabilities it doesn't need, by accident or by malice.

cdrecord neither does drop the privileges by accident nor by malice.
What I however see is that a completely unneeded incompatible interface change 
has been applied to a _stable_ Kernel.

On a cleanly designed OS with fine grained permissions, a program like cdrecord
does not need to worry about the permissions as it gets exactly the needed 
permissions granted by the execution environment.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: (was: Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices)

[John Myers]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joerg Schilling wrote:
| John Myers <electronerd@monolith3d.com> wrote:
|
|
|>I hope this is not a stupid idea:
|>
|>I propose a finer-grained approach to suid-root binaries. Perhaps,
|>instead of having a single flag giving the binary all the rights and
|>responsibilities of its owner, there could be a table/list/something of
|>capabilities which we want to grant to the binary. This, of course,
|>would be a privileged operation (perhaps a new capability?).
|>
|>For example, we might want to grant cdrecord CAP_SYS_RAWIO. This way, we
|>don't have to worry about cdrecord running as root and not dropping all
|>the capabilities it doesn't need, by accident or by malice.
|
|
| cdrecord neither does drop the privileges by accident nor by malice.

I wasn't trying to insult cdrecord, or even suggest it might have the
inkling of a possibility of this type of issue, and I am sorry if I made
it sound that way. I was merely trying to illustrate a use of my
proposal. I admit, I should have invented a name, like
cd-burning-fire-toaster-program to illustrate the separation of my
example from any actual existing implementation

| What I however see is that a completely unneeded incompatible
interface change
| has been applied to a _stable_ Kernel.

I really wasn't talking about that. I was, however, trying to offer a
solution that would, perhaps, allow both this change, and cdrecord, to
co-exist peacefully, without running cdrecord as root.

|
| On a cleanly designed OS with fine grained permissions, a program like
cdrecord
| does not need to worry about the permissions as it gets exactly the
needed
| permissions granted by the execution environment.
|
| Jörg
|

Which is exactly what I proposed...


So... could anyone comment on my proposal, rather than just flame my
examples?

- --
electronerd (jonathan s myers)
code poet and recycle bin monitor
programmer, monolith3d.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBNyUBNh5QaxZowccRAtGYAJ4gLta/cmcRpDQoDf3u1bdEdx8vKwCgikzM
xVI2EyH2pwRbUI/KgLGP7YQ=
=Sxlq
-----END PGP SIGNATURE-----

Re: (was: Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices)

[Joerg Schilling]

John Myers <electronerd@monolith3d.com> wrote:

> | cdrecord neither does drop the privileges by accident nor by malice.
>
> I wasn't trying to insult cdrecord, or even suggest it might have the
> inkling of a possibility of this type of issue, and I am sorry if I made
> it sound that way. I was merely trying to illustrate a use of my
> proposal. I admit, I should have invented a name, like
> cd-burning-fire-toaster-program to illustrate the separation of my
> example from any actual existing implementation

It was not you, but other people did write that cdrecord is broken
although only the kernel did change in an incompatible way.

> | On a cleanly designed OS with fine grained permissions, a program like
> cdrecord
> | does not need to worry about the permissions as it gets exactly the
> needed
> | permissions granted by the execution environment.
> |
> | Jörg
> |
>
> Which is exactly what I proposed...
>
>
> So... could anyone comment on my proposal, rather than just flame my
> examples?

I did not flame your examples, but if you thought of the same thigs, you may 
have been not obvious enough with your explanation.

On Solaris, this is done by /usr/bin/pfexec (the only suid root binary) that 
calls /usr/bin/ppriv -e which executes a process with the privilleges that are 
in the privilleges database.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Julien Oster]

Pascal Schmidt <der.eremit@email.de> writes:

Hello Pascal,

> The open question is whether write permission really is meaningful
> enough to allow arbitrary SCSI commands. I personally think "being
> able to wipe the drive firmware" is too much, and since filtering
> of vendor commands is generally impossible to do right, sending SG_IO
> should require CAP_SYS_RAWIO capability.

But what about the following (the first 3 points are already
familiar):

1. require read permission to do read()
2. require write premission to do write()
3. require CAP_SYS_RAWIO to do SG_IO
4. insert an initially blank (i.e. "drop everything") userspace
   controllable filter which allows the administrator to specify
   allowed SG_IO commands to the kernel at any time

That way there is no security problem, CD burning as root or generally
with CAP_SYS_RAWIO is always possible *and* admins are able to submit a
list of allowed commands to the kernel, so that CD burning as user is
possible again. This list might be specific to the CD writer hardware,
as we learned that some drives require vendor specific commands.

Prewritten filter lists for specific hardware can be published on
internet or even be submitted by cdrecord or other burning software,
i.e. with a switch "--install-filter" as root.

The filters should be separate for each SCSI device, so that you won't
enable dangerous commands on harddisk partitions when you just wanted
to enable CD burning.

If nobody else volunteers, I'll see if I can prepare a patch. I guess
sysfs is the right place for the userspace interface to the filters?

Regards,
Julien

Linux Kernel bug report (includes fix)

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]

-	Linux Kernel include files (starting with Linux-2.5) are buggy and 
	prevent compilation. Many files may be affected but let me name
	the most important files for me:

	-	/usr/src/linux/include/scsi/scsi.h depends on a nonexistant
		type "u8". The correct way to fix this would be to replace
		any "u8" by "uint8_t". A quick and dirty fix is to call:

			"change u8 __u8 /usr/src/linux/include/scsi/scsi.h"

		ftp://ftp.berlios.de/pub/change/

	-	/usr/src/linux/include/scsi/sg.h includes "extra text" "__user"
		in some structure definitions. This may be fixed by adding
		#include <linux/compiler.h> somewhere at the beginning of
		/usr/src/linux/include/scsi/sg.h

	This bug has been reported several times (starting with Linux-2.5).

	Time to fix: 5 minutes.
	
I did spend far to much time with the discussion on LKML..... so I need a cue
whether it makes sense to continue this discussion.

You now again have the bug report _and_ the fix in a single short mail.

If the bug mentioned above is not fixed in Linux-2.6.8, I will asume that it 
makes no sense to spend further time in discussions with LKML.

Best regards

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: Linux Kernel bug report (includes fix)

[Måns Rullgård]

Joerg Schilling <schilling@fokus.fraunhofer.de> writes:

> You now again have the bug report _and_ the fix in a single short mail.

I could see no patch contained in your mail.

-- 
Måns Rullgård
mru@kth.se

Re: Linux Kernel bug report (includes fix)

[Bernd Schubert]

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

On Saturday 07 August 2004 15:26, Måns Rullgård wrote:
> Joerg Schilling <schilling@fokus.fraunhofer.de> writes:
> > You now again have the bug report _and_ the fix in a single short mail.
>
> I could see no patch contained in your mail.

I guess thats what Joerg wants to have.

Cheers,
	Bernd

[-- Attachment #2: scsi_head_patch.out --]
[-- Type: text/x-csrc, Size: 1934 bytes --]

diff -ru linux-2.6.8-rc2-mm2.bak/include/scsi/scsi.h linux-2.6.8-rc2-mm2/include/scsi/scsi.h
--- linux-2.6.8-rc2-mm2.bak/include/scsi/scsi.h	2004-06-16 07:20:25.000000000 +0200
+++ linux-2.6.8-rc2-mm2/include/scsi/scsi.h	2004-08-07 20:51:27.000000000 +0200
@@ -214,25 +214,25 @@
  */
 
 struct ccs_modesel_head {
-	u8 _r1;			/* reserved */
-	u8 medium;		/* device-specific medium type */
-	u8 _r2;			/* reserved */
-	u8 block_desc_length;	/* block descriptor length */
-	u8 density;		/* device-specific density code */
-	u8 number_blocks_hi;	/* number of blocks in this block desc */
-	u8 number_blocks_med;
-	u8 number_blocks_lo;
-	u8 _r3;
-	u8 block_length_hi;	/* block length for blocks in this desc */
-	u8 block_length_med;
-	u8 block_length_lo;
+	uint8_t _r1;			/* reserved */
+	uint8_t medium;		/* device-specific medium type */
+	uint8_t _r2;			/* reserved */
+	uint8_t block_desc_length;	/* block descriptor length */
+	uint8_t density;		/* device-specific density code */
+	uint8_t number_blocks_hi;	/* number of blocks in this block desc */
+	uint8_t number_blocks_med;
+	uint8_t number_blocks_lo;
+	uint8_t _r3;
+	uint8_t block_length_hi;	/* block length for blocks in this desc */
+	uint8_t block_length_med;
+	uint8_t block_length_lo;
 };
 
 /*
  * ScsiLun: 8 byte LUN.
  */
 struct scsi_lun {
-	u8 scsi_lun[8];
+	uint8_t scsi_lun[8];
 };
 
 /*
diff -ru linux-2.6.8-rc2-mm2.bak/include/scsi/sg.h linux-2.6.8-rc2-mm2/include/scsi/sg.h
--- linux-2.6.8-rc2-mm2.bak/include/scsi/sg.h	2004-08-03 13:22:50.000000000 +0200
+++ linux-2.6.8-rc2-mm2/include/scsi/sg.h	2004-08-07 20:53:41.000000000 +0200
@@ -89,6 +89,8 @@
 
 /* New interface introduced in the 3.x SG drivers follows */
 
+#include <linux/compiler.h>
+
 typedef struct sg_iovec /* same structure as used by readv() Linux system */
 {                       /* call. It defines one scatter-gather element. */
     void __user *iov_base;      /* Starting address  */

Re: Linux Kernel bug report (includes fix)

[Horst von Brand]

Joerg Schilling <schilling@fokus.fraunhofer.de> said:
> -	Linux Kernel include files (starting with Linux-2.5) are buggy and 
> 	prevent compilation.

They do not, the kernel compiles just fine. They are _not_ to be used for
random userspace programs.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: Linux Kernel bug report (includes fix)

[Alexander E. Patrakov]

Horst von Brand wrote:
> Joerg Schilling <schilling@fokus.fraunhofer.de> said:
> 
>>-	Linux Kernel include files (starting with Linux-2.5) are buggy and 
>>	prevent compilation.
> 
> 
> They do not, the kernel compiles just fine. They are _not_ to be used for
> random userspace programs.

You are supposed to either bring the needed "sanitized" kernel headers 
with your program, or have those provided by the linux-libc-headers 
(http://ep09.pld-linux.org/~mmazur/linux-libc-headers/) in /usr/include. 
Adding /usr/src/linux/include to the gcc search path is a bug in 
userspace programs.

-- 
Alexander E. Patrakov