linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: CD writing in future Linux (stirring up a hornets' nest) (was:   Rationale for RLIMIT_MEMLOCK?)
       [not found]                   ` <5yi2X-zm-7@gated-at.bofh.it>
@ 2006-01-24  9:14                     ` Bodo Eggert
  2006-01-24 14:38                       ` Joerg Schilling
  0 siblings, 1 reply; 37+ messages in thread
From: Bodo Eggert @ 2006-01-24  9:14 UTC (permalink / raw)
  To: Joerg Schilling, rlrevell, matthias.andree, schilling, linux-kernel

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

[...]
> On Solaris, you (currently) use a profile enabled shell (pfsh, pfksh or pfcsh)
> that calls getexecuser() in order to find whether there is a specific
> treatment needed. If this specific treatment is needed, then the shell calls
> execve(/usr/bin/pfexec cmd <args>)
> else it calls  execve(cmd <args>)
> 
> I did recently voted to require all shells to be profile enabled by default.

Why? I asume there will only be few programs requiring to be run by a
wrapper, and mv /usr/bin/foo to /usr/pfexec-bin/foo;
echo $'#!/bin/sh\n/usr/sbin/pfexec /usr/pfexec-bin/foo "$@"' > /usr/bin/foo;
chmod 755 /usr/bin/foo
should be easier than patching e.g. all callers of cdrecord, and it won't
slow down starting non-profiled applications.

Possibly the pfexec can tell the application to be run by the basename (like
su1), in this case you'd add something like
"alias cdrecord /opt/schily/bin/cdrecord" to it's configuration and link it
to /usr/bin/cdrecord.

> With the future plans for extending fine grained privs on Solaris, sending
> SCSI commands will become more than one priv.
> 
> I proposed to have a low priv right to send commands like inquiry and test
> unit ready. These commands may e.g. be send without interfering a concurrent
> CD/DVD write operation.
> 
> The next priv could be the permission for sending simple SCSI commands that
> allow reading from the device.
> 
> The next priv could be the permission for sending simple SCSI Commands that
> allow writing.
> 
> The final priv would allow even vendor specific commands: this is what
> cdrecord needs.

That sounds reasonable, but I wonder how you can get access to a device
file descriptor in order to do unprivileged access.
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was:    Rationale for RLIMIT_MEMLOCK?)
  2006-01-24  9:14                     ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Bodo Eggert
@ 2006-01-24 14:38                       ` Joerg Schilling
  2006-01-24 17:44                         ` CD writing in future Linux (stirring up a hornets' nest) Bodo Eggert
  0 siblings, 1 reply; 37+ messages in thread
From: Joerg Schilling @ 2006-01-24 14:38 UTC (permalink / raw)
  To: schilling, rlrevell, matthias.andree, linux-kernel, 7eggert

Bodo Eggert <harvested.in.lkml@7eggert.dyndns.org> wrote:

> Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
>
> [...]
> > On Solaris, you (currently) use a profile enabled shell (pfsh, pfksh or pfcsh)
> > that calls getexecuser() in order to find whether there is a specific
> > treatment needed. If this specific treatment is needed, then the shell calls
> > execve(/usr/bin/pfexec cmd <args>)
> > else it calls  execve(cmd <args>)
> > 
> > I did recently voted to require all shells to be profile enabled by default.
>
> Why? I asume there will only be few programs requiring to be run by a
> wrapper, and mv /usr/bin/foo to /usr/pfexec-bin/foo;
> echo $'#!/bin/sh\n/usr/sbin/pfexec /usr/pfexec-bin/foo "$@"' > /usr/bin/foo;
> chmod 755 /usr/bin/foo
> should be easier than patching e.g. all callers of cdrecord, and it won't
> slow down starting non-profiled applications.

Because the architecture review commitee decided this would be the right way.

Note that we are on a migration from the classical root/non-root UNIX to a fine 
grained privileges handling. The current documentation says that you need to 
have a profile enabled shell as your SHELL in order to be able to use a 
root-less Solaris.

> Possibly the pfexec can tell the application to be run by the basename (like
> su1), in this case you'd add something like
> "alias cdrecord /opt/schily/bin/cdrecord" to it's configuration and link it
> to /usr/bin/cdrecord.

But you are right that another way would be to use something like "isaexec"

> > The final priv would allow even vendor specific commands: this is what
> > cdrecord needs.
>
> That sounds reasonable, but I wonder how you can get access to a device
> file descriptor in order to do unprivileged access.

This is something that needs to be discussed. Last night, I found that there 
should be a way to run cdrecord without the need to have the "file_dac_read"
provilege. I'll discuss this with the security group.



Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest)
  2006-01-24 14:38                       ` Joerg Schilling
@ 2006-01-24 17:44                         ` Bodo Eggert
  0 siblings, 0 replies; 37+ messages in thread
From: Bodo Eggert @ 2006-01-24 17:44 UTC (permalink / raw)
  To: Joerg Schilling; +Cc: rlrevell, matthias.andree, linux-kernel, 7eggert

On Tue, 24 Jan 2006, Joerg Schilling wrote:
> Bodo Eggert <harvested.in.lkml@7eggert.dyndns.org> wrote:
> > Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> > [...]
> > > On Solaris, you (currently) use a profile enabled shell (pfsh, pfksh or pfcsh)
> > > that calls getexecuser() in order to find whether there is a specific
> > > treatment needed. If this specific treatment is needed, then the shell calls
> > > execve(/usr/bin/pfexec cmd <args>)
> > > else it calls  execve(cmd <args>)
> > > 
> > > I did recently voted to require all shells to be profile enabled by default.
> >
> > Why? I asume there will only be few programs requiring to be run by a
> > wrapper, and mv /usr/bin/foo to /usr/pfexec-bin/foo;
> > echo $'#!/bin/sh\n/usr/sbin/pfexec /usr/pfexec-bin/foo "$@"' > /usr/bin/foo;
> > chmod 755 /usr/bin/foo
> > should be easier than patching e.g. all callers of cdrecord, and it won't
> > slow down starting non-profiled applications.
> 
> Because the architecture review commitee decided this would be the right way.
> 
> Note that we are on a migration from the classical root/non-root UNIX to a fine 
> grained privileges handling. The current documentation says that you need to 
> have a profile enabled shell as your SHELL in order to be able to use a 
> root-less Solaris.

If the shell was the only program calling cdrecord, this would work out as 
expected.
-- 
My mail reader can beat up your mail reader. 

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Rationale for RLIMIT_MEMLOCK?
       [not found]                         ` <5yUUI-6JR-15@gated-at.bofh.it>
@ 2006-01-26  0:12                           ` Bodo Eggert
  0 siblings, 0 replies; 37+ messages in thread
From: Bodo Eggert @ 2006-01-26  0:12 UTC (permalink / raw)
  To: Joerg Schilling, schilling, matthias.andree, linux-kernel, tytso, arjan

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

> I could add this piece of code to the euid == 0 part of cdrecord:
> 
> LOCAL void
> raise_memlock()
> { 
> #ifdef  RLIMIT_MEMLOCK
>         struct rlimit rlim;
>  
>         rlim.rlim_cur = rlim.rlim_max = RLIM_INFINITY;

I think you should rather use the size you're going to mlock, or at least
the upper bound.
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-02-06 17:25                               ` Joerg Schilling
@ 2006-02-07 10:57                                 ` Matthias Andree
  0 siblings, 0 replies; 37+ messages in thread
From: Matthias Andree @ 2006-02-07 10:57 UTC (permalink / raw)
  To: Joerg Schilling; +Cc: Linux-Kernel mailing list

Joerg Schilling schrieb am 2006-02-06:

> Peter Read <peter.read@gmail.com> wrote:
> 
> > I'm confused about where software has inherited a sense of morality from?
> >
> > Equally, as I can't see any restriction of the GPL in that link I
> > don't get the reference.  What it's essentially saying to me is 'if
> > you don't want it under the GPL licence terms, talk to the copyright
> > holder(s) or their authorised representative about alternatives'.
> 
> Please read again carefully. It says that it is not allowed to be shipped
> together with commercial software unless the publisher did pay money.

The topic is still cdrecord with Linux, growisofs and dvd+rw-tools
discussion is a matter for a separate thread.

-- 
Matthias Andree

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was:  Rationale for RLIMIT_MEMLOCK?)
  2006-02-06 13:51                           ` Joerg Schilling
  2006-02-06 14:01                             ` Matthias Andree
  2006-02-06 15:06                             ` Peter Read
@ 2006-02-06 17:40                             ` Luke-Jr
  2 siblings, 0 replies; 37+ messages in thread
From: Luke-Jr @ 2006-02-06 17:40 UTC (permalink / raw)
  To: Joerg Schilling; +Cc: jengelh, rlrevell, matthias.andree, linux-kernel

On Monday 06 February 2006 13:51, Joerg Schilling wrote:
> Luke-Jr <luke@dashjr.org> wrote:
> > ProDVD is immoral software. I use growisofs.
>
> growisofs is immoral, see
>
> 	http://fy.chalmers.se/~appro/linux/DVD+RW/solaris.com.html
>
> Either this, or the GPL applies, but not both as intended by the author....

You can dual license any work. Someone who receives growisofs under this 
license would not be allowed to redistribute it without permission granted 
therein. However, if that same person receives growisofs under the GPL 
license, the GPL terms apply. A GPL license only applies if the person has 
received the software under those terms. While most GPL'd software is 
available online under the GPL license, making it effectively everyone to 
receive the license, it is not necessary.

On Monday 06 February 2006 17:25, you wrote:
> Peter Read <peter.read@gmail.com> wrote:
> > I'm confused about where software has inherited a sense of morality from?
> >
> > Equally, as I can't see any restriction of the GPL in that link I
> > don't get the reference.  What it's essentially saying to me is 'if
> > you don't want it under the GPL licence terms, talk to the copyright
> > holder(s) or their authorised representative about alternatives'.
>
> Please read again carefully. It says that it is not allowed to be shipped
> together with commercial software unless the publisher did pay money.

However, that applies only for that particular license. If the publisher 
obtains the rights elsewhere (eg, the GPL licensed version), then they may do 
so provided they comply with the rest of the GPL terms. Note that the GPL 
prohibits distributing growisofs linked to non-GPL-compatible software. Thus, 
if Solaris is not under a GPL-compatible license, the GPL prohibits 
distributing growisofs with it.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was:  Rationale for RLIMIT_MEMLOCK?)
  2006-02-06 15:06                             ` Peter Read
@ 2006-02-06 17:25                               ` Joerg Schilling
  2006-02-07 10:57                                 ` Matthias Andree
  0 siblings, 1 reply; 37+ messages in thread
From: Joerg Schilling @ 2006-02-06 17:25 UTC (permalink / raw)
  To: schilling, peter.read, luke
  Cc: rlrevell, matthias.andree, linux-kernel, jengelh

Peter Read <peter.read@gmail.com> wrote:

> I'm confused about where software has inherited a sense of morality from?
>
> Equally, as I can't see any restriction of the GPL in that link I
> don't get the reference.  What it's essentially saying to me is 'if
> you don't want it under the GPL licence terms, talk to the copyright
> holder(s) or their authorised representative about alternatives'.

Please read again carefully. It says that it is not allowed to be shipped
together with commercial software unless the publisher did pay money.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-02-06 13:51                           ` Joerg Schilling
  2006-02-06 14:01                             ` Matthias Andree
@ 2006-02-06 15:06                             ` Peter Read
  2006-02-06 17:25                               ` Joerg Schilling
  2006-02-06 17:40                             ` Luke-Jr
  2 siblings, 1 reply; 37+ messages in thread
From: Peter Read @ 2006-02-06 15:06 UTC (permalink / raw)
  To: Joerg Schilling, luke; +Cc: rlrevell, matthias.andree, linux-kernel, jengelh

I'm confused about where software has inherited a sense of morality from?

Equally, as I can't see any restriction of the GPL in that link I
don't get the reference.  What it's essentially saying to me is 'if
you don't want it under the GPL licence terms, talk to the copyright
holder(s) or their authorised representative about alternatives'.

Plenty of people are happy to dual licence their work, & TBH I'd
rather see people do that and get something for their work than have
it misappropriated into commercial software and have to look to the
courts for a slim chance at compensation...

Anyone else rather get back to the technical discussion or is it just me?

On 06/02/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Luke-Jr <luke@dashjr.org> wrote:
>
> > ProDVD is immoral software. I use growisofs.
>
> growisofs is immoral, see
>
>         http://fy.chalmers.se/~appro/linux/DVD+RW/solaris.com.html
>
> Either this, or the GPL applies, but not both as intended by the author....
>
> Jörg
>
> --
>  EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
>        js@cs.tu-berlin.de                (uni)
>        schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
>  URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-02-06 13:51                           ` Joerg Schilling
@ 2006-02-06 14:01                             ` Matthias Andree
  2006-02-06 15:06                             ` Peter Read
  2006-02-06 17:40                             ` Luke-Jr
  2 siblings, 0 replies; 37+ messages in thread
From: Matthias Andree @ 2006-02-06 14:01 UTC (permalink / raw)
  To: Joerg Schilling; +Cc: luke, jengelh, rlrevell, matthias.andree, linux-kernel

Joerg Schilling schrieb am 2006-02-06:

> Luke-Jr <luke@dashjr.org> wrote:
> 
> > ProDVD is immoral software. I use growisofs.
> 
> growisofs is immoral, see 
> 
> 	http://fy.chalmers.se/~appro/linux/DVD+RW/solaris.com.html
> 
> Either this, or the GPL applies, but not both as intended by the author....

Who cares. You start complaining even about GPL patches for the software
you distributed under the terms of the GPL, without looking at
patches...

-- 
Matthias Andree

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was:  Rationale for RLIMIT_MEMLOCK?)
  2006-02-03 17:24                         ` Luke-Jr
@ 2006-02-06 13:51                           ` Joerg Schilling
  2006-02-06 14:01                             ` Matthias Andree
                                               ` (2 more replies)
  0 siblings, 3 replies; 37+ messages in thread
From: Joerg Schilling @ 2006-02-06 13:51 UTC (permalink / raw)
  To: luke, jengelh; +Cc: schilling, rlrevell, matthias.andree, linux-kernel

Luke-Jr <luke@dashjr.org> wrote:

> ProDVD is immoral software. I use growisofs.

growisofs is immoral, see 

	http://fy.chalmers.se/~appro/linux/DVD+RW/solaris.com.html

Either this, or the GPL applies, but not both as intended by the author....

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-02-03 14:08                       ` Jan Engelhardt
  2006-02-03 16:50                         ` Joerg Schilling
@ 2006-02-03 17:24                         ` Luke-Jr
  2006-02-06 13:51                           ` Joerg Schilling
  1 sibling, 1 reply; 37+ messages in thread
From: Luke-Jr @ 2006-02-03 17:24 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Matthias Andree, Lee Revell, Joerg Schilling, linux-kernel

On Friday 03 February 2006 14:08, Jan Engelhardt wrote:
> >> >2. find out the current state of affairs,
> >>
> >> I am currently able to properly write all sorts of CD-R/RW and DVD±R/RW,
> >> DVD-DL with no problems using
> >>     cdrecord -dev=/dev/hdb
> >> it _currently_ works, no matter how ugly or not this is from either
> >> Jörg's or any other developer's POV - therefore it's fine from the
> >> end-user's POV.
> >
> >How did you manage to burn a dual layer disc? I have been completely
> >unsuccessful at doing this at all. :(
>
> You have to add  -driver=mmc_dvdplusr , because the Dual Layer discs are
> not yet in the ProDVD database as it seems.

ProDVD is immoral software. I use growisofs.

> >> I'm fine (=I agree) with the general possibility of having it setuid,
> >> though.
> >
> >Provided it doesn't allow burning files the real-user shouldn't be able to
> >access... But since cdrecord is commonly suid-root, I presume this has
> > long been taken into consideration.
>
> Security-critical environments like data centers

I'm not referring to anything security-critical, but basic minimal UNIX file 
permissions. If I have a file that's go-r, I expect that Joe Random User 
can't burn a CD/DVD with that file.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was:  Rationale for RLIMIT_MEMLOCK?)
  2006-02-03 14:08                       ` Jan Engelhardt
@ 2006-02-03 16:50                         ` Joerg Schilling
  2006-02-03 17:24                         ` Luke-Jr
  1 sibling, 0 replies; 37+ messages in thread
From: Joerg Schilling @ 2006-02-03 16:50 UTC (permalink / raw)
  To: luke, jengelh; +Cc: schilling, rlrevell, matthias.andree, linux-kernel

Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> >> >2. find out the current state of affairs,
> >>
> >> I am currently able to properly write all sorts of CD-R/RW and DVD±R/RW,
> >> DVD-DL with no problems using
> >>     cdrecord -dev=/dev/hdb
> >> it _currently_ works, no matter how ugly or not this is from either Jörg's
> >> or any other developer's POV - therefore it's fine from the end-user's POV.
> >
> >How did you manage to burn a dual layer disc? I have been completely 
> >unsuccessful at doing this at all. :(
> >
>
> You have to add  -driver=mmc_dvdplusr , because the Dual Layer discs are 
> not yet in the ProDVD database as it seems.

They are if you use a halfway recent cdrecord.

> userwhat? You mean supplemental groups as printed by id(1)? I find them 
> ugly, because it's a real hassle to manage it with files.
>
> In the past, NGROUPS_MAX also was 32, being more of a limit than today.

If you extend NGROUPS_MAX to be more than 16, NFS AUTH_UNIX will not work 
anymore.

And BTW: using NGROUPS seems to be a bit outdated now, more than 10 years after
ACLs have been introduced on UNIX.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-02-02 17:17                     ` Luke-Jr
@ 2006-02-03 14:08                       ` Jan Engelhardt
  2006-02-03 16:50                         ` Joerg Schilling
  2006-02-03 17:24                         ` Luke-Jr
  0 siblings, 2 replies; 37+ messages in thread
From: Jan Engelhardt @ 2006-02-03 14:08 UTC (permalink / raw)
  To: Luke-Jr; +Cc: Matthias Andree, Lee Revell, Joerg Schilling, linux-kernel

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2053 bytes --]

>> >2. find out the current state of affairs,
>>
>> I am currently able to properly write all sorts of CD-R/RW and DVD±R/RW,
>> DVD-DL with no problems using
>>     cdrecord -dev=/dev/hdb
>> it _currently_ works, no matter how ugly or not this is from either Jörg's
>> or any other developer's POV - therefore it's fine from the end-user's POV.
>
>How did you manage to burn a dual layer disc? I have been completely 
>unsuccessful at doing this at all. :(
>

You have to add  -driver=mmc_dvdplusr , because the Dual Layer discs are 
not yet in the ProDVD database as it seems.

>> I'm fine (=I agree) with the general possibility of having it setuid,
>> though.
>
>Provided it doesn't allow burning files the real-user shouldn't be able to 
>access... But since cdrecord is commonly suid-root, I presume this has long 
>been taken into consideration.
>
Security-critical environments like data centers either have a Windows 
NT-style machine providing <enter whacky burning software here>, or they 
've got a specialized machine that is marked "use for cd burning - note 
security implications". Usually there is no problem with that as in that 
case, you should remove your ISO you copied over for writing after writing.

>> SUSE currently does it in A Nice Way: setfacl'ing the devices to include
>> read access for currently logged-in users. (Well, if someone logs on tty1
>> after you, you're screwed anyway - he could have just ejected the cd when
>> he's physically at the box.)
>
>Aren't user-groups per-session anyway? Why not simply have the login program 
>apply a 'localusers' group to all local sessions and set device permissions 
>for that group?

userwhat? You mean supplemental groups as printed by id(1)? I find them 
ugly, because it's a real hassle to manage it with files.

In the past, NGROUPS_MAX also was 32, being more of a limit than today.

>To add to the security, perhaps there is a way to remove the 
>'localusers' permissions from all backgrounded processes (screen, etc) when 
>the user logs out?
>


Jan Engelhardt
-- 

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-01-24 17:42                   ` Jan Engelhardt
  2006-01-25 14:04                     ` Joerg Schilling
@ 2006-02-02 17:17                     ` Luke-Jr
  2006-02-03 14:08                       ` Jan Engelhardt
  1 sibling, 1 reply; 37+ messages in thread
From: Luke-Jr @ 2006-02-02 17:17 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Matthias Andree, Lee Revell, Joerg Schilling, linux-kernel

On Tuesday 24 January 2006 17:42, Jan Engelhardt wrote:
> >2. find out the current state of affairs,
>
> I am currently able to properly write all sorts of CD-R/RW and DVD±R/RW,
> DVD-DL with no problems using
>     cdrecord -dev=/dev/hdb
> it _currently_ works, no matter how ugly or not this is from either Jörg's
> or any other developer's POV - therefore it's fine from the end-user's POV.

How did you manage to burn a dual layer disc? I have been completely 
unsuccessful at doing this at all. :(

> There have been reports that cdrecord does not work when setuid, but only
> when you are "truly root". Not sure where this comes from,
> (current->euid==0&&current->uid!=0 maybe?) scsi layer somewhere?

I didn't look into it, but my cdrecord seems to work fine as my normal user 
(writing via cdrw group w/ perms), but not with suid-root.

> I'm fine (=I agree) with the general possibility of having it setuid,
> though.

Provided it doesn't allow burning files the real-user shouldn't be able to 
access... But since cdrecord is commonly suid-root, I presume this has long 
been taken into consideration.

> SUSE currently does it in A Nice Way: setfacl'ing the devices to include
> read access for currently logged-in users. (Well, if someone logs on tty1
> after you, you're screwed anyway - he could have just ejected the cd when
> he's physically at the box.)

Aren't user-groups per-session anyway? Why not simply have the login program 
apply a 'localusers' group to all local sessions and set device permissions 
for that group? To add to the security, perhaps there is a way to remove the 
'localusers' permissions from all backgrounded processes (screen, etc) when 
the user logs out?


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-01-26 21:33                               ` Vadim Lobanov
@ 2006-01-26 21:48                                 ` Gene Heskett
  0 siblings, 0 replies; 37+ messages in thread
From: Gene Heskett @ 2006-01-26 21:48 UTC (permalink / raw)
  To: linux-kernel

On Thursday 26 January 2006 16:33, Vadim Lobanov wrote:
>On Thu, 26 Jan 2006, Jan Engelhardt wrote:
>> (removing Jens and Lee, as previous posts made that quite clear)
>>
>> >> I'm getting a grin:
>> >>
>> >> 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0
>> >> grep SG_IO (no results)
>> >>
>> >> Looks like it's already non-redundant :)
>> >
>> >everything in drivers/block/scsi_ioctl.c  is duplicate code and I
>> > am sure I would find more if I take some time....
>>
>> In what linux kernel version have you found that file?
>
>In taking a look at http://sosdg.org/~coywolf/lxr/ ...
>That file exists in versions 2.6.10 through 2.6.14. It's gone from
>2.6.15 and onward, however.
>No comment as to the validity of its contents to the argument at hand.
No, its apparently been moved (works for IBM maybe?)

#>locate scsi_ioctl.c
/usr/gene/src/linux-2.4.29/drivers/scsi/scsi_ioctl.c
/usr/gene/src/linux-2.4.21-pre7/drivers/scsi/scsi_ioctl.c
/usr/gene/src/linux-2.4.18-4/drivers/scsi/scsi_ioctl.c
/usr/gene/src/linux-2.4.19/drivers/scsi/scsi_ioctl.c
/usr/gene/src/linux-2.4.21-rc1-ck6/drivers/scsi/scsi_ioctl.c
/usr/gene/src/linux-2.4.21-pre5/drivers/scsi/scsi_ioctl.c
/usr/src/2.6.15-rc2-git6.bak/drivers/scsi/scsi_ioctl.c
/usr/src/2.6.15-rc2-git6.bak/block/scsi_ioctl.c
/usr/src/2.6.14.3-bak/drivers/block/scsi_ioctl.c
/usr/src/2.6.14.3-bak/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15-rc2-git6/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15-rc2-git6/block/scsi_ioctl.c
/usr/src/linux-2.6.15/block/scsi_ioctl.c
/usr/src/linux-2.6.15/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15-rc3/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15-rc3/block/scsi_ioctl.c
/usr/src/linux-2.6.14.2-pktwrt/drivers/block/scsi_ioctl.c
/usr/src/linux-2.6.14.2-pktwrt/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.14.1/drivers/block/scsi_ioctl.c
/usr/src/linux-2.6.14.1/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.14.3/drivers/block/scsi_ioctl.c
/usr/src/linux-2.6.14.3/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15-rc4/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15-rc4/block/scsi_ioctl.c
/usr/src/linux-2.6.15-rc5/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15-rc5/block/scsi_ioctl.c
/usr/src/kernel/git-core-0.99.7/linux/drivers/block/scsi_ioctl.c
/usr/src/kernel/git-core-0.99.7/linux/drivers/scsi/scsi_ioctl.c
/usr/src/kernel/linux/drivers/block/scsi_ioctl.c
/usr/src/kernel/linux/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15-rc6/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15-rc6/block/scsi_ioctl.c
/usr/src/linux-2.6.15-rc7/block/scsi_ioctl.c
/usr/src/linux-2.6.15-rc7/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15.1/block/scsi_ioctl.c
/usr/src/linux-2.6.15.1/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.15.1/linux-2.6.15/block/scsi_ioctl.c
/usr/src/linux-2.6.15.1/linux-2.6.15/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.6.16-rc1/block/scsi_ioctl.c
/usr/src/linux-2.6.16-rc1/drivers/scsi/scsi_ioctl.c <----------
/usr/src/linux-2.4.23-pre8/drivers/scsi/scsi_ioctl.c
/usr/src/linux-2.4.23-pre8/linux-2.4.22/drivers/scsi/scsi_ioctl.c

And obviously its time for me to go on a housekeeping binge :)

-- 
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules.  I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-01-26 21:06                             ` Jan Engelhardt
  2006-01-26 21:33                               ` Vadim Lobanov
@ 2006-01-26 21:34                               ` Vadim Lobanov
  1 sibling, 0 replies; 37+ messages in thread
From: Vadim Lobanov @ 2006-01-26 21:34 UTC (permalink / raw)
  To: Jan Engelhardt
  Cc: Joerg Schilling, matthias.andree, Linux Kernel Mailing List

On Thu, 26 Jan 2006, Jan Engelhardt wrote:

>
> (removing Jens and Lee, as previous posts made that quite clear)
>
> >> I'm getting a grin:
> >>
> >> 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO
> >> (no results)
> >>
> >> Looks like it's already non-redundant :)
> >
> >everything in drivers/block/scsi_ioctl.c  is duplicate code and I am sure I
> >would find more if I take some time....
>
> In what linux kernel version have you found that file?
>

In looking at http://sosdg.org/~coywolf/lxr/, that file seems to exist
in versions 2.6.10 through 2.6.14. It's gone in versions 2.6.15 and
upward, however. No comment as to the validity of that file's contents
to the discussion at hand, however. :-)

>
> Jan Engelhardt
> --

- Vadim Lobanov

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-01-26 21:06                             ` Jan Engelhardt
@ 2006-01-26 21:33                               ` Vadim Lobanov
  2006-01-26 21:48                                 ` Gene Heskett
  2006-01-26 21:34                               ` Vadim Lobanov
  1 sibling, 1 reply; 37+ messages in thread
From: Vadim Lobanov @ 2006-01-26 21:33 UTC (permalink / raw)
  To: Jan Engelhardt
  Cc: Joerg Schilling, matthias.andree, Linux Kernel Mailing List

On Thu, 26 Jan 2006, Jan Engelhardt wrote:

>
> (removing Jens and Lee, as previous posts made that quite clear)
>
> >> I'm getting a grin:
> >>
> >> 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO
> >> (no results)
> >>
> >> Looks like it's already non-redundant :)
> >
> >everything in drivers/block/scsi_ioctl.c  is duplicate code and I am sure I
> >would find more if I take some time....
>
> In what linux kernel version have you found that file?
>

In taking a look at http://sosdg.org/~coywolf/lxr/ ...
That file exists in versions 2.6.10 through 2.6.14. It's gone from
2.6.15 and onward, however.
No comment as to the validity of its contents to the argument at hand.
:-)

>
> Jan Engelhardt
> --

- Vadim Lobanov

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-01-25 16:57                           ` Joerg Schilling
  2006-01-25 17:20                             ` Jens Axboe
  2006-01-25 20:16                             ` Lee Revell
@ 2006-01-26 21:06                             ` Jan Engelhardt
  2006-01-26 21:33                               ` Vadim Lobanov
  2006-01-26 21:34                               ` Vadim Lobanov
  2 siblings, 2 replies; 37+ messages in thread
From: Jan Engelhardt @ 2006-01-26 21:06 UTC (permalink / raw)
  To: Joerg Schilling; +Cc: matthias.andree, Linux Kernel Mailing List


(removing Jens and Lee, as previous posts made that quite clear)

>> I'm getting a grin:
>>
>> 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO
>> (no results)
>>
>> Looks like it's already non-redundant :)
>
>everything in drivers/block/scsi_ioctl.c  is duplicate code and I am sure I 
>would find more if I take some time....

In what linux kernel version have you found that file?



Jan Engelhardt
-- 

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-01-25 14:04                     ` Joerg Schilling
  2006-01-25 14:21                       ` Jens Axboe
@ 2006-01-26 12:32                       ` Pavel Machek
  1 sibling, 0 replies; 37+ messages in thread
From: Pavel Machek @ 2006-01-26 12:32 UTC (permalink / raw)
  To: Joerg Schilling; +Cc: matthias.andree, jengelh, rlrevell, linux-kernel

Hi!

> > >write a CD anyways". I find this wrong, J??rg finds it correct and argues
> > >"if you can access /dev/hdc as unprivileged user, that's a security
> > >problem".
> >
> > If you can access a _harddisk_ as a normal user, you _do have_ a security 
> > problem. If you can access a cdrom as normal user, well, the opinions 
> > differ here. I think you _should not either_, because it might happen that 
> > you just left your presentation cd in a cdrom device in a public box. You 
> > would certainly not want to have everyone read that out.
> 
> Do you  want everybody to be able to read or format a floppy disk?

Why not... if I'm on box without network access, for example.

> > SUSE currently does it in A Nice Way: setfacl'ing the devices to include 
> > read access for currently logged-in users. (Well, if someone logs on tty1 
> > after you, you're screwed anyway - he could have just ejected the cd when 
> > he's physically at the box.)
> 
> It may make sense to do something like this for the user logged into the 
> console. In general it is a security problem.

Violent agreement here. For some uses, 99% of users are logged onto
the console.
								Pavel
-- 
Thanks, Sharp!

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-01-25 16:57                           ` Joerg Schilling
  2006-01-25 17:20                             ` Jens Axboe
@ 2006-01-25 20:16                             ` Lee Revell
  2006-01-26 21:06                             ` Jan Engelhardt
  2 siblings, 0 replies; 37+ messages in thread
From: Lee Revell @ 2006-01-25 20:16 UTC (permalink / raw)
  To: Joerg Schilling; +Cc: jengelh, axboe, matthias.andree, linux-kernel

On Wed, 2006-01-25 at 17:57 +0100, Joerg Schilling wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
> >
> > >> And if you check the amount of completely unneeded code Linux currently has 
> > >> just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the 
> > >> kernel when converting to a clean SCSI based design.
> > >
> > >Please point me at that huge amount of code. Hint: there is none.
> >
> > I'm getting a grin:
> >
> > 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO
> > (no results)
> >
> > Looks like it's already non-redundant :)
> 
> everything in drivers/block/scsi_ioctl.c  is duplicate code and I am sure I 
> would find more if I take some time....

PLEASE don't cc: me on this asinine thread anymore.

Argh, I KNEW this would end with the same exact flame war.

Lee


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-01-25 17:00                             ` Joerg Schilling
@ 2006-01-25 17:23                               ` Jens Axboe
  0 siblings, 0 replies; 37+ messages in thread
From: Jens Axboe @ 2006-01-25 17:23 UTC (permalink / raw)
  To: Joerg Schilling; +Cc: jengelh, rlrevell, matthias.andree, linux-kernel

On Wed, Jan 25 2006, Joerg Schilling wrote:
> Jens Axboe <axboe@suse.de> wrote:
> 
> > It just looks like Joerg needs to do his homework, before spreading
> > false information on lkml. Then again, all his "arguments" are the same
> > as last time (and the time before, and before, and so on).
> 
> Before spreading your false claims, please do your homework.

Sorry Joerg, _you_ really are the one that has to do your homework as
you aptly demonstrated.

> We previously had mostly fruitful discussion before you did appear.
> Please either try to contribute useful ideas or stay out.

You are spreading blatently false claim about the code and repeating the
same old suggestions on what _you_ think Linux design should be like. So
I had to correct it, which I did.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-01-25 16:57                           ` Joerg Schilling
@ 2006-01-25 17:20                             ` Jens Axboe
  2006-01-25 20:16                             ` Lee Revell
  2006-01-26 21:06                             ` Jan Engelhardt
  2 siblings, 0 replies; 37+ messages in thread
From: Jens Axboe @ 2006-01-25 17:20 UTC (permalink / raw)
  To: Joerg Schilling; +Cc: jengelh, rlrevell, matthias.andree, linux-kernel

On Wed, Jan 25 2006, Joerg Schilling wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
> >
> > >> And if you check the amount of completely unneeded code Linux currently has 
> > >> just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the 
> > >> kernel when converting to a clean SCSI based design.
> > >
> > >Please point me at that huge amount of code. Hint: there is none.
> >
> > I'm getting a grin:
> >
> > 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO
> > (no results)
> >
> > Looks like it's already non-redundant :)
> 
> everything in drivers/block/scsi_ioctl.c  is duplicate code and I am sure I 
> would find more if I take some time....

axboe@nelson:[.]r/src/linux-2.6-block.git $ size block/scsi_ioctl.o
   text    data     bss     dec     hex filename
   2844     256       0    3100     c1c block/scsi_ioctl.o

And it's not everything that's duplicated, basically only the ioctl
parsing is. So either admit that there isn't a a lot of duplicated code,
or "take some time" and point me at it. Otherwise refrain from making
obviously false statements in the future.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was:  Rationale for RLIMIT_MEMLOCK?)
  2006-01-25 14:55                           ` Jens Axboe
  2006-01-25 14:58                             ` Jens Axboe
@ 2006-01-25 17:00                             ` Joerg Schilling
  2006-01-25 17:23                               ` Jens Axboe
  1 sibling, 1 reply; 37+ messages in thread
From: Joerg Schilling @ 2006-01-25 17:00 UTC (permalink / raw)
  To: jengelh, axboe; +Cc: schilling, rlrevell, matthias.andree, linux-kernel

Jens Axboe <axboe@suse.de> wrote:

> It just looks like Joerg needs to do his homework, before spreading
> false information on lkml. Then again, all his "arguments" are the same
> as last time (and the time before, and before, and so on).

Before spreading your false claims, please do your homework.

We previously had mostly fruitful discussion before you did appear.
Please either try to contribute useful ideas or stay out.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was:  Rationale for RLIMIT_MEMLOCK?)
  2006-01-25 14:47                         ` Jan Engelhardt
  2006-01-25 14:55                           ` Jens Axboe
@ 2006-01-25 16:57                           ` Joerg Schilling
  2006-01-25 17:20                             ` Jens Axboe
                                               ` (2 more replies)
  1 sibling, 3 replies; 37+ messages in thread
From: Joerg Schilling @ 2006-01-25 16:57 UTC (permalink / raw)
  To: jengelh, axboe; +Cc: schilling, rlrevell, matthias.andree, linux-kernel

Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

>
> >> And if you check the amount of completely unneeded code Linux currently has 
> >> just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the 
> >> kernel when converting to a clean SCSI based design.
> >
> >Please point me at that huge amount of code. Hint: there is none.
>
> I'm getting a grin:
>
> 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO
> (no results)
>
> Looks like it's already non-redundant :)

everything in drivers/block/scsi_ioctl.c  is duplicate code and I am sure I 
would find more if I take some time....

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-01-25 14:55                           ` Jens Axboe
@ 2006-01-25 14:58                             ` Jens Axboe
  2006-01-25 17:00                             ` Joerg Schilling
  1 sibling, 0 replies; 37+ messages in thread
From: Jens Axboe @ 2006-01-25 14:58 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Joerg Schilling, matthias.andree, rlrevell, linux-kernel

On Wed, Jan 25 2006, Jens Axboe wrote:
> On Wed, Jan 25 2006, Jan Engelhardt wrote:
> > 
> > >> And if you check the amount of completely unneeded code Linux currently has 
> > >> just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the 
> > >> kernel when converting to a clean SCSI based design.
> > >
> > >Please point me at that huge amount of code. Hint: there is none.
> > 
> > I'm getting a grin:
> > 
> > 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO
> > (no results)
> > 
> > Looks like it's already non-redundant :)
> 
> SG_IO turns requests into REQ_BLOCK_PC (or blk_pc_request()) types, so
> you should probably check for that as well. But it's truly a miniscule
> amount of code, and if I got off my ass and folded cdrom_newpc_intr()
> and cdrom_pc_intr() into one (that was the intention), it would be even
> less.

BTW, I should point out that the fact that references to REQ_BLOCK_PC
and blk_pc_request() exists doesn't indicate duplicated code. Each low
level driver or layer (like SCSI, not the SCSI low level drivers) need
to transform REQ_BLOCK_PC requests into their command types.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-01-25 14:47                         ` Jan Engelhardt
@ 2006-01-25 14:55                           ` Jens Axboe
  2006-01-25 14:58                             ` Jens Axboe
  2006-01-25 17:00                             ` Joerg Schilling
  2006-01-25 16:57                           ` Joerg Schilling
  1 sibling, 2 replies; 37+ messages in thread
From: Jens Axboe @ 2006-01-25 14:55 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Joerg Schilling, matthias.andree, rlrevell, linux-kernel

On Wed, Jan 25 2006, Jan Engelhardt wrote:
> 
> >> And if you check the amount of completely unneeded code Linux currently has 
> >> just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the 
> >> kernel when converting to a clean SCSI based design.
> >
> >Please point me at that huge amount of code. Hint: there is none.
> 
> I'm getting a grin:
> 
> 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO
> (no results)
> 
> Looks like it's already non-redundant :)

SG_IO turns requests into REQ_BLOCK_PC (or blk_pc_request()) types, so
you should probably check for that as well. But it's truly a miniscule
amount of code, and if I got off my ass and folded cdrom_newpc_intr()
and cdrom_pc_intr() into one (that was the intention), it would be even
less.

It just looks like Joerg needs to do his homework, before spreading
false information on lkml. Then again, all his "arguments" are the same
as last time (and the time before, and before, and so on).

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-01-25 14:21                       ` Jens Axboe
@ 2006-01-25 14:47                         ` Jan Engelhardt
  2006-01-25 14:55                           ` Jens Axboe
  2006-01-25 16:57                           ` Joerg Schilling
  0 siblings, 2 replies; 37+ messages in thread
From: Jan Engelhardt @ 2006-01-25 14:47 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Joerg Schilling, matthias.andree, rlrevell, linux-kernel


>> And if you check the amount of completely unneeded code Linux currently has 
>> just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the 
>> kernel when converting to a clean SCSI based design.
>
>Please point me at that huge amount of code. Hint: there is none.

I'm getting a grin:

15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO
(no results)

Looks like it's already non-redundant :)



Jan Engelhardt
-- 

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-01-25 14:04                     ` Joerg Schilling
@ 2006-01-25 14:21                       ` Jens Axboe
  2006-01-25 14:47                         ` Jan Engelhardt
  2006-01-26 12:32                       ` Pavel Machek
  1 sibling, 1 reply; 37+ messages in thread
From: Jens Axboe @ 2006-01-25 14:21 UTC (permalink / raw)
  To: Joerg Schilling; +Cc: matthias.andree, jengelh, rlrevell, linux-kernel

On Wed, Jan 25 2006, Joerg Schilling wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
> > >1. compile a list of their requirements,
> >
> > Have as few code duplicated (e.g. ATAPI and SCSI may share some - after 
> > all, ATAPI is (to me) some sort of SCSI tunneled in ATA.)
> 
> Thank you! This is a vote _pro_ a unified SCSI generic implementation for all
> types of devices. The current implementation unneccssarily duplicates a lot 
> of code.

The block layer SG_IO is just that, it's completely transport agnostic.
There's not a lot of duplicated code. In the future, perhaps sg will
disappear and be replaced by bsg which is just the full block layer
implementation of that (SG_IO can currently be considered a subset of
that support).

> > Make it, in accordance with the above, possible to have as few kernel 
> > modules loaded as possible and therefore reducing footprint - if I had not 
> > to load sd_mod for usb_storage fun, I would get an itch to load a 78564 
> > byte scsi_mod module just to be able to use ATAPI. (MINOR one, though.)
> 
> On Solaris, the SCSI glue code (between hostadaptor drivers and target drivers) is 
> really small:
> 
> /usr/ccs/bin/size /kernel/misc/scsi 
> 28482 + 27042 + 2036 = 57560
> 
> And if you check the amount of completely unneeded code Linux currently has 
> just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the 
> kernel when converting to a clean SCSI based design.

Please point me at that huge amount of code. Hint: there is none.

Deja vu, anyone?

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was:  Rationale for RLIMIT_MEMLOCK?)
  2006-01-24 17:42                   ` Jan Engelhardt
@ 2006-01-25 14:04                     ` Joerg Schilling
  2006-01-25 14:21                       ` Jens Axboe
  2006-01-26 12:32                       ` Pavel Machek
  2006-02-02 17:17                     ` Luke-Jr
  1 sibling, 2 replies; 37+ messages in thread
From: Joerg Schilling @ 2006-01-25 14:04 UTC (permalink / raw)
  To: matthias.andree, jengelh; +Cc: schilling, rlrevell, linux-kernel

Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> >1. compile a list of their requirements,
>
> Have as few code duplicated (e.g. ATAPI and SCSI may share some - after 
> all, ATAPI is (to me) some sort of SCSI tunneled in ATA.)

Thank you! This is a vote _pro_ a unified SCSI generic implementation for all
types of devices. The current implementation unneccssarily duplicates a lot 
of code.

> Make it, in accordance with the above, possible to have as few kernel 
> modules loaded as possible and therefore reducing footprint - if I had not 
> to load sd_mod for usb_storage fun, I would get an itch to load a 78564 
> byte scsi_mod module just to be able to use ATAPI. (MINOR one, though.)

On Solaris, the SCSI glue code (between hostadaptor drivers and target drivers) is 
really small:

/usr/ccs/bin/size /kernel/misc/scsi 
28482 + 27042 + 2036 = 57560

And if you check the amount of completely unneeded code Linux currently has 
just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the 
kernel when converting to a clean SCSI based design.


> Want to write CDs and DVDs "as usual" (see below).

Be careful: libscg is a _generic_ SCSI transport library.
Closing the eyes for anything but CD writing is not the right way.


> De-forest the SCSI subsystem for privilege checking (see below).

Sorry, I see nothing related below.


> >2. find out the current state of affairs,
>
> I am currently able to properly write all sorts of CD-R/RW and DVD±R/RW, 
> DVD-DL with no problems using
>     cdrecord -dev=/dev/hdb

Maybe I should enforce the official libscg device syntax in order to prevent 
this from working in the future.

Anyway: the fact that it may work is no proof for correctness.


> I can write DVDs at 8x speed (approx 10816 KB/sec) - which looks like DMA 
> is working through the current mechanism, although I can't confirm it.

In case you don't knw the story:

	Linus Torvalds once claimed that introducing SG_IO support for
	/dev/hd* would be acompanied with cleaning up DMA support in the kernel.

	At that moment it turned out that it did not help at all as /dev/hd*
	did not give DMA. Later this bug was fixed, but I am still waiting
	to see the proposed DMA fix for ide-scsi.


> There have been reports that cdrecord does not work when setuid, but only 
> when you are "truly root". Not sure where this comes from,
> (current->euid==0&&current->uid!=0 maybe?) scsi layer somewhere?

Depends on what you talk about. 

Since about a year, there is a workaround for the incompatible interface change 
introduced with Linux-2.6.8.1

On a recent RedHat system, cdrecord works installed suid root.

On a system running a kernel.org based Linux it has been reported to fail
because it does not get a SCSI transfer buffer.



> >write a CD anyways". I find this wrong, Jörg finds it correct and argues
> >"if you can access /dev/hdc as unprivileged user, that's a security
> >problem".
>
> If you can access a _harddisk_ as a normal user, you _do have_ a security 
> problem. If you can access a cdrom as normal user, well, the opinions 
> differ here. I think you _should not either_, because it might happen that 
> you just left your presentation cd in a cdrom device in a public box. You 
> would certainly not want to have everyone read that out.

Do you  want everybody to be able to read or format a floppy disk?
Ignoring usual security rules sometimes _seem_ to make life easier but usually 
does not. Just look in what kind of jungle Microsoft is just because that 
started to allow insanely things for the sake of "user convenience".


> SUSE currently does it in A Nice Way: setfacl'ing the devices to include 
> read access for currently logged-in users. (Well, if someone logs on tty1 
> after you, you're screwed anyway - he could have just ejected the cd when 
> he's physically at the box.)

It may make sense to do something like this for the user logged into the 
console. In general it is a security problem.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-01-23 21:21                 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Matthias Andree
                                     ` (3 preceding siblings ...)
  2006-01-24 13:58                   ` Joerg Schilling
@ 2006-01-24 17:42                   ` Jan Engelhardt
  2006-01-25 14:04                     ` Joerg Schilling
  2006-02-02 17:17                     ` Luke-Jr
  4 siblings, 2 replies; 37+ messages in thread
From: Jan Engelhardt @ 2006-01-24 17:42 UTC (permalink / raw)
  To: Matthias Andree; +Cc: Lee Revell, Joerg Schilling, linux-kernel

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3094 bytes --]


I'm joining in,
>
>1. compile a list of their requirements,

Have as few code duplicated (e.g. ATAPI and SCSI may share some - after 
all, ATAPI is (to me) some sort of SCSI tunneled in ATA.)

Make it, in accordance with the above, possible to have as few kernel 
modules loaded as possible and therefore reducing footprint - if I had not 
to load sd_mod for usb_storage fun, I would get an itch to load a 78564 
byte scsi_mod module just to be able to use ATAPI. (MINOR one, though.)

Want to write CDs and DVDs "as usual" (see below).

De-forest the SCSI subsystem for privilege checking (see below).


>2. find out the current state of affairs,

I am currently able to properly write all sorts of CD-R/RW and DVD±R/RW, 
DVD-DL with no problems using
    cdrecord -dev=/dev/hdb
it _currently_ works, no matter how ugly or not this is from either Jörg's 
or any other developer's POV - therefore it's fine from the end-user's POV.

I can write DVDs at 8x speed (approx 10816 KB/sec) - which looks like DMA 
is working through the current mechanism, although I can't confirm it.

There have been reports that cdrecord does not work when setuid, but only 
when you are "truly root". Not sure where this comes from,
(current->euid==0&&current->uid!=0 maybe?) scsi layer somewhere?

I'm fine (=I agree) with the general possibility of having it setuid, 
though.

>3. match the lists found in 1 and 2
>
>4. ONLY AFTER THAT negotiate who is going to change what to make things
>   work better for us end users.

>S3 Device enumeration/probing is a sore spot. Unprivileged "cdrecord
>dev=ATA: -scandisk" doesn't work, and recent discussions on the cdwrite@
>list didn't make any progress. My observation is that cdrecord stops
>probing /dev/hd* devices as soon as one yields EPERM, on the assumption
>"if I cannot access /dev/hda, I will not have sufficient privilege to
>write a CD anyways". I find this wrong, Jörg finds it correct and argues
>"if you can access /dev/hdc as unprivileged user, that's a security
>problem".

If you can access a _harddisk_ as a normal user, you _do have_ a security 
problem. If you can access a cdrom as normal user, well, the opinions 
differ here. I think you _should not either_, because it might happen that 
you just left your presentation cd in a cdrom device in a public box. You 
would certainly not want to have everyone read that out.

SUSE currently does it in A Nice Way: setfacl'ing the devices to include 
read access for currently logged-in users. (Well, if someone logs on tty1 
after you, you're screwed anyway - he could have just ejected the cd when 
he's physically at the box.)

Yes, the device numbering is not optimal. (I already hear someone saying 
'have udev make some sweety symlink in /dev'.)
But in case of /dev/hd*, we are pretty sure of what device is connected 
where. In case of sd*, it's AFAICS not - the next device plugged in gets 
the next free sd slot.


Jan Engelhardt
-- 
| Software Engineer and Linux/Unix Network Administrator
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was:  Rationale for RLIMIT_MEMLOCK?)
  2006-01-23 21:21                 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Matthias Andree
                                     ` (2 preceding siblings ...)
  2006-01-23 22:03                   ` Joerg Schilling
@ 2006-01-24 13:58                   ` Joerg Schilling
  2006-01-24 17:42                   ` Jan Engelhardt
  4 siblings, 0 replies; 37+ messages in thread
From: Joerg Schilling @ 2006-01-24 13:58 UTC (permalink / raw)
  To: rlrevell, matthias.andree; +Cc: schilling, linux-kernel

Matthias Andree <matthias.andree@gmx.de> wrote:

> Of course, I think it's sensible to expect that Linux should adhere to
> standards (POSIX) as far as possible, and if any precedent
> implementations that are standards-conformant are found, I'd suggest
> that Linux adheres to their interpretation, too, to reduce the clutter
> and make applications more easily ported to Linux. We'll all benefit.

With respect to SCSI transport, it would also make sense tolook at the 
implementations of various other platforms.


> LIST 1 # REQUIREMENTS
>
> R1 I'll just say we all want cdrecord, dvd recording applications and
> similar to work without setuid root flags or sudo or other excessive
> privilege escalation. (This needs to be split up into I/O access
> privileges, device enumeration, buffer allocation, real-time
> requirements such as locking buffers into memory, scheduling and so on.)

With fine grained privileges and a nice inherent user level framework, this 
kind of problems should not apear inside cdrecord at all.


> LIST 2 # CURRENT STATE
>
> S1 Jörg is unhappy with /dev/hd* because he says that it is inferior to
> the sg-access via ide-scsi. (I believe the original issues were
> DMA-based, and I don't know the details.) I hope Jörg will fill in the
> operations that ide-cd (/dev/hd*) lacks. (Jörg, please don't talk about
> layer violations here).

One original issue was that ide-scsi did cause a kernel panic in case it
was used on top of PCMCIA based ATA.

The other issue is that ide-scsi does not do DMA in case DMA-size is not
a multiple of 512 while is is needed for any size % 4 == 0;
or at least size % 8 == 0


> S2 Jörg is concerned about the SCSI command filter being too
> restrictive. I'm not sure if it still applies to 2.6.16-rc and what the
> exact commands in question were. I'll let Jörg complete this list.

If this change had been announced early anough and if there was a workaround,
there would be no problem. The problem was that someone has a bad dream and
incompatibly changed the Linux kernel over night while cdrecord was in code 
freeze. Later I was called unflexible because I did follow the well known 
quality ensuring rules that are in effect short before a new stable/final 
released is published.


> S3 Device enumeration/probing is a sore spot. Unprivileged "cdrecord
> dev=ATA: -scandisk" doesn't work, and recent discussions on the cdwrite@
> list didn't make any progress. My observation is that cdrecord stops
> probing /dev/hd* devices as soon as one yields EPERM, on the assumption
> "if I cannot access /dev/hda, I will not have sufficient privilege to
> write a CD anyways". I find this wrong, Jörg finds it correct and argues
> "if you can access /dev/hdc as unprivileged user, that's a security
> problem".

This are two problems:

-	users of cdrecord like to run cdrecord -scanbus in order to find all
	SCSI devices. This no longer works since the non-orthogonal /dev/hd* 
	SCSI transport has been added.

	As Linux already implements a Generic SCSI transport interface 
	(/dev/sg*) people would asume to be able to talk to _all_ SCSI devices
	using this interface. To allows this, there is a need for a 
	SCSI HBA driver that sends SCSI commands via a ATA interface.

-	some people seem to set the permissions of some of the /dev/hd* 
	nodes to unsafe values and then complain that the other /dev/hd* 
	nodes cannot be opened.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was:  Rationale for RLIMIT_MEMLOCK?)
  2006-01-23 21:21                 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Matthias Andree
  2006-01-23 21:26                   ` Lee Revell
  2006-01-23 21:30                   ` Lee Revell
@ 2006-01-23 22:03                   ` Joerg Schilling
  2006-01-24 13:58                   ` Joerg Schilling
  2006-01-24 17:42                   ` Jan Engelhardt
  4 siblings, 0 replies; 37+ messages in thread
From: Joerg Schilling @ 2006-01-23 22:03 UTC (permalink / raw)
  To: rlrevell, matthias.andree; +Cc: schilling, linux-kernel

Matthias Andree <matthias.andree@gmx.de> wrote:

> S2 Jörg is concerned about the SCSI command filter being too
> restrictive. I'm not sure if it still applies to 2.6.16-rc and what the
> exact commands in question were. I'll let Jörg complete this list.

I am tired today and I need to do other work, so let me parly reply:

Iff there is a user space infrastructure for fine grained privileges,
there is absolutely no problem with a planned and well known restriction.

On Solaris, you (currently) use a profile enabled shell (pfsh, pfksh or pfcsh)
that calls getexecuser() in order to find whether there is a specific treatment 
needed. If this specific treatment is needed, then the shell calls 
execve(/usr/bin/pfexec cmd <args>)
else it calls  execve(cmd <args>)

I did recently voted to require all shells to be profile enabled by default.

With the future plans for extending fine grained privs on Solaris, sending
SCSI commands will become more than one priv.

I proposed to have a low priv right to send commands like inquiry and test unit 
ready. These commands may e.g. be send without interfering a concurrent CD/DVD 
write operation.

The next priv could be the permission for sending simple SCSI commands that 
allow reading from the device.

The next priv could be the permission for sending simple SCSI Commands that
allow writing.

The final priv would allow even vendor specific commands: this is what cdrecord 
needs.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-01-23 21:45                     ` Joerg Schilling
@ 2006-01-23 22:00                       ` Lee Revell
  0 siblings, 0 replies; 37+ messages in thread
From: Lee Revell @ 2006-01-23 22:00 UTC (permalink / raw)
  To: Joerg Schilling; +Cc: matthias.andree, linux-kernel

On Mon, 2006-01-23 at 22:45 +0100, Joerg Schilling wrote:
> Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > On Mon, 2006-01-23 at 22:21 +0100, Matthias Andree wrote:
> > > Sounds really good. Can you give a pointer as to the detailed rlimit
> > > requirements? 
> >
> > I don't want to touch the rest of the thread, but the best info on the
> > above can be found in the linux-audio-user list archives.  It's still a
> > little unclear exactly which packages are required, but IIRC PAM 0.80
> > supports it already.  I believe this requires glibc changes eventually,
> > but programs like PAM and bash that deal with rlimits can work around it
> > if glibc is not aware of the new rlimit.
> 
> Could you explain this more in depth?
> 
> What you describe looks like you propose to add a line:
> 
> joerg::::defaultpriv=file_dac_read,sys_devices,proc_lock_memory,proc_priocntl,net_privaddr
> 
> to /etc/user_attr which would be honored by PAM during login.
> 
> This is not what I like to see.
> 
> What I like to see is that only specific programs like cdrecord
> would get the permissions to do more than joe user.

It's not that fine grained, it works at a user/group level.

You would add a line like:

@cdrecord        hard    rtprio           80

to /etc/security/limits.conf and add users to the cdrecord group.

Lee


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was:  Rationale for RLIMIT_MEMLOCK?)
  2006-01-23 21:26                   ` Lee Revell
@ 2006-01-23 21:45                     ` Joerg Schilling
  2006-01-23 22:00                       ` Lee Revell
  0 siblings, 1 reply; 37+ messages in thread
From: Joerg Schilling @ 2006-01-23 21:45 UTC (permalink / raw)
  To: rlrevell, matthias.andree; +Cc: schilling, linux-kernel

Lee Revell <rlrevell@joe-job.com> wrote:

> On Mon, 2006-01-23 at 22:21 +0100, Matthias Andree wrote:
> > Sounds really good. Can you give a pointer as to the detailed rlimit
> > requirements? 
>
> I don't want to touch the rest of the thread, but the best info on the
> above can be found in the linux-audio-user list archives.  It's still a
> little unclear exactly which packages are required, but IIRC PAM 0.80
> supports it already.  I believe this requires glibc changes eventually,
> but programs like PAM and bash that deal with rlimits can work around it
> if glibc is not aware of the new rlimit.

Could you explain this more in depth?

What you describe looks like you propose to add a line:

joerg::::defaultpriv=file_dac_read,sys_devices,proc_lock_memory,proc_priocntl,net_privaddr

to /etc/user_attr which would be honored by PAM during login.

This is not what I like to see.

What I like to see is that only specific programs like cdrecord
would get the permissions to do more than joe user.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-01-23 21:21                 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Matthias Andree
  2006-01-23 21:26                   ` Lee Revell
@ 2006-01-23 21:30                   ` Lee Revell
  2006-01-23 22:03                   ` Joerg Schilling
                                     ` (2 subsequent siblings)
  4 siblings, 0 replies; 37+ messages in thread
From: Lee Revell @ 2006-01-23 21:30 UTC (permalink / raw)
  To: Matthias Andree; +Cc: Joerg Schilling, linux-kernel

On Mon, 2006-01-23 at 22:21 +0100, Matthias Andree wrote:
> On Mon, 23 Jan 2006, Lee Revell wrote:
> 
> > You will be happy to know that in future Linux distros, cdrecord will
> > not require setuid to mlock() and get SCHED_FIFO - both are now
> > controlled by rlimits, so if the distro ships with a sane PAM/group
> > configuration, all you will need to do is add cdrecord users to the
> > "realtime" or "cdrecord" or "audio" group.
> 
> Sounds really good. Can you give a pointer as to the detailed rlimit
> requirements?

One thing I believe is still unresolved is that despite the new rlimits,
sched_get_priority_max(SCHED_FIFO) always returns 99 rather than
RLIMIT_RTPRIO.

Lee 


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-01-23 21:21                 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Matthias Andree
@ 2006-01-23 21:26                   ` Lee Revell
  2006-01-23 21:45                     ` Joerg Schilling
  2006-01-23 21:30                   ` Lee Revell
                                     ` (3 subsequent siblings)
  4 siblings, 1 reply; 37+ messages in thread
From: Lee Revell @ 2006-01-23 21:26 UTC (permalink / raw)
  To: Matthias Andree; +Cc: Joerg Schilling, linux-kernel

On Mon, 2006-01-23 at 22:21 +0100, Matthias Andree wrote:
> Sounds really good. Can you give a pointer as to the detailed rlimit
> requirements? 

I don't want to touch the rest of the thread, but the best info on the
above can be found in the linux-audio-user list archives.  It's still a
little unclear exactly which packages are required, but IIRC PAM 0.80
supports it already.  I believe this requires glibc changes eventually,
but programs like PAM and bash that deal with rlimits can work around it
if glibc is not aware of the new rlimit.

Personally I still use the old realtime LSM, until this is all worked
out.

Lee


^ permalink raw reply	[flat|nested] 37+ messages in thread

* CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
  2006-01-23 20:30               ` Lee Revell
@ 2006-01-23 21:21                 ` Matthias Andree
  2006-01-23 21:26                   ` Lee Revell
                                     ` (4 more replies)
  0 siblings, 5 replies; 37+ messages in thread
From: Matthias Andree @ 2006-01-23 21:21 UTC (permalink / raw)
  To: Lee Revell; +Cc: Joerg Schilling, linux-kernel

On Mon, 23 Jan 2006, Lee Revell wrote:

> You will be happy to know that in future Linux distros, cdrecord will
> not require setuid to mlock() and get SCHED_FIFO - both are now
> controlled by rlimits, so if the distro ships with a sane PAM/group
> configuration, all you will need to do is add cdrecord users to the
> "realtime" or "cdrecord" or "audio" group.

Sounds really good. Can you give a pointer as to the detailed rlimit
requirements?

Anyways, this seems like a very good point in time to pick up the old
discussion of ide-scsi, ide-cd and thereabouts, because your
announcement met Jörg's criterion that Linux had to make a step forward
in his direction before he'd try to negotiate again.

I'm more of a user who is annoyed by this war of warning messages
(ide-scsi claiming it's unsuitable for CD writing, cdrecord calling
/dev/hd* badly designed, and all that), and I'd appreciate if people
could just

1. compile a list of their requirements,

2. find out the current state of affairs,

3. match the lists found in 1 and 2

4. ONLY AFTER THAT negotiate who is going to change what to make things
   work better for us end users.

Of course, I think it's sensible to expect that Linux should adhere to
standards (POSIX) as far as possible, and if any precedent
implementations that are standards-conformant are found, I'd suggest
that Linux adheres to their interpretation, too, to reduce the clutter
and make applications more easily ported to Linux. We'll all benefit.

LIST 1 # REQUIREMENTS

R1 I'll just say we all want cdrecord, dvd recording applications and
similar to work without setuid root flags or sudo or other excessive
privilege escalation. (This needs to be split up into I/O access
privileges, device enumeration, buffer allocation, real-time
requirements such as locking buffers into memory, scheduling and so on.)

LIST 2 # CURRENT STATE

S1 Jörg is unhappy with /dev/hd* because he says that it is inferior to
the sg-access via ide-scsi. (I believe the original issues were
DMA-based, and I don't know the details.) I hope Jörg will fill in the
operations that ide-cd (/dev/hd*) lacks. (Jörg, please don't talk about
layer violations here).

S2 Jörg is concerned about the SCSI command filter being too
restrictive. I'm not sure if it still applies to 2.6.16-rc and what the
exact commands in question were. I'll let Jörg complete this list.

S3 Device enumeration/probing is a sore spot. Unprivileged "cdrecord
dev=ATA: -scandisk" doesn't work, and recent discussions on the cdwrite@
list didn't make any progress. My observation is that cdrecord stops
probing /dev/hd* devices as soon as one yields EPERM, on the assumption
"if I cannot access /dev/hda, I will not have sufficient privilege to
write a CD anyways". I find this wrong, Jörg finds it correct and argues
"if you can access /dev/hdc as unprivileged user, that's a security
problem".

These topics I brought up are my recollections from memory, without
archive research, that I deem worth developing into either requirements
or "state-of-the-art" assertions of the "we're already there" kind.

Please, everybody, ONLY list what you would like to do, why, why it
doesn't work. Please DO NOT TELL THE OTHER SIDE HOW they are supposed to
do it, unless it's worded as a polite and patient question. We've been
there, and it didn't work.

I hope this is getting a more fruitful discussion than last time.

-- 
Matthias Andree

^ permalink raw reply	[flat|nested] 37+ messages in thread

end of thread, other threads:[~2006-02-07 10:57 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <5y7B5-1dw-15@gated-at.bofh.it>
     [not found] ` <5y7KL-1DZ-31@gated-at.bofh.it>
     [not found]   ` <5yddh-1pA-47@gated-at.bofh.it>
     [not found]     ` <5ydni-1Qq-3@gated-at.bofh.it>
     [not found]       ` <5yek1-3iP-53@gated-at.bofh.it>
     [not found]         ` <5yeth-3us-33@gated-at.bofh.it>
     [not found]           ` <5yf5O-4iF-19@gated-at.bofh.it>
     [not found]             ` <5yfI4-5kU-11@gated-at.bofh.it>
     [not found]               ` <5ygE4-6LK-35@gated-at.bofh.it>
     [not found]                 ` <5yhqg-7ZR-5@gated-at.bofh.it>
     [not found]                   ` <5yi2X-zm-7@gated-at.bofh.it>
2006-01-24  9:14                     ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Bodo Eggert
2006-01-24 14:38                       ` Joerg Schilling
2006-01-24 17:44                         ` CD writing in future Linux (stirring up a hornets' nest) Bodo Eggert
     [not found]               ` <5ygDT-6LK-3@gated-at.bofh.it>
     [not found]                 ` <5yscc-68j-5@gated-at.bofh.it>
     [not found]                   ` <5ysvk-6JI-5@gated-at.bofh.it>
     [not found]                     ` <5ysvk-6JI-3@gated-at.bofh.it>
     [not found]                       ` <5yEn7-7Or-21@gated-at.bofh.it>
     [not found]                         ` <5yUUI-6JR-15@gated-at.bofh.it>
2006-01-26  0:12                           ` Rationale for RLIMIT_MEMLOCK? Bodo Eggert
2006-01-23 10:56 Matthias Andree
2006-01-23 11:05 ` Arjan van de Ven
2006-01-23 16:54   ` Matthias Andree
2006-01-23 17:00     ` Arjan van de Ven
2006-01-23 18:01       ` Matthias Andree
2006-01-23 18:13         ` Arjan van de Ven
2006-01-23 18:55           ` Matthias Andree
2006-01-23 19:38             ` Joerg Schilling
2006-01-23 20:30               ` Lee Revell
2006-01-23 21:21                 ` CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) Matthias Andree
2006-01-23 21:26                   ` Lee Revell
2006-01-23 21:45                     ` Joerg Schilling
2006-01-23 22:00                       ` Lee Revell
2006-01-23 21:30                   ` Lee Revell
2006-01-23 22:03                   ` Joerg Schilling
2006-01-24 13:58                   ` Joerg Schilling
2006-01-24 17:42                   ` Jan Engelhardt
2006-01-25 14:04                     ` Joerg Schilling
2006-01-25 14:21                       ` Jens Axboe
2006-01-25 14:47                         ` Jan Engelhardt
2006-01-25 14:55                           ` Jens Axboe
2006-01-25 14:58                             ` Jens Axboe
2006-01-25 17:00                             ` Joerg Schilling
2006-01-25 17:23                               ` Jens Axboe
2006-01-25 16:57                           ` Joerg Schilling
2006-01-25 17:20                             ` Jens Axboe
2006-01-25 20:16                             ` Lee Revell
2006-01-26 21:06                             ` Jan Engelhardt
2006-01-26 21:33                               ` Vadim Lobanov
2006-01-26 21:48                                 ` Gene Heskett
2006-01-26 21:34                               ` Vadim Lobanov
2006-01-26 12:32                       ` Pavel Machek
2006-02-02 17:17                     ` Luke-Jr
2006-02-03 14:08                       ` Jan Engelhardt
2006-02-03 16:50                         ` Joerg Schilling
2006-02-03 17:24                         ` Luke-Jr
2006-02-06 13:51                           ` Joerg Schilling
2006-02-06 14:01                             ` Matthias Andree
2006-02-06 15:06                             ` Peter Read
2006-02-06 17:25                               ` Joerg Schilling
2006-02-07 10:57                                 ` Matthias Andree
2006-02-06 17:40                             ` Luke-Jr

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).