Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Bodo Eggert]

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.

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Joerg Schilling]

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

Re: CD writing in future Linux (stirring up a hornets' nest)

[Bodo Eggert]

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. 

Re: Rationale for RLIMIT_MEMLOCK?

[Bodo Eggert]

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.

Rationale for RLIMIT_MEMLOCK?

[Matthias Andree]

Greetings,

debugging an application problem that used to mlockall(...FUTURE) and
failed with a subsequent mmap(), I came across the manual page for
setrlimit (see below for the relevant excerpt). I have several questions
concerning the rationale:

1. What is the reason we're having special treatment
   for the super-user here?

2. Why is it the opposite of what 2.6.8.1 and earlier did?

3. Why is this inconsistent with all other RLIMIT_*?
   Neither of which cares if a process is privileged or not.

4. Is the default hard limit of 32 kB initialized by the kernel or
   by some script in SUSE 10.0? If it's the kernel: why is the limit so
   low, and why isn't just the soft limit set?

   "[...]
    RLIMIT_MEMLOCK
      The maximum number of bytes of memory that may  be  locked  into
      RAM.  In effect this limit is rounded down to the nearest multi-
      ple of the system page size.  This limit  affects  mlock(2)  and
      mlockall(2)  and  the mmap(2) MAP_LOCKED operation.  Since Linux
      2.6.9 it also affects the shmctl(2) SHM_LOCK operation, where it
      sets a maximum on the total bytes in shared memory segments (see
      shmget(2)) that may be locked by the real user ID of the calling
      process.   The  shmctl(2) SHM_LOCK locks are accounted for sepa-
      rately  from  the  per-process  memory  locks   established   by
      mlock(2),  mlockall(2),  and  mmap(2)  MAP_LOCKED; a process can
      lock bytes up to this limit in each of these two categories.  In
      Linux  kernels before 2.6.9, this limit controlled the amount of
      memory that could be locked  by  a  privileged  process.   Since
      Linux 2.6.9, no limits are placed on the amount of memory that a
      privileged process may lock, and this limit instead governs  the
      amount of memory that an unprivileged process may lock. [...]"
   (getrlimit(2), man-pages-2.07)

-- 
Matthias Andree

Re: Rationale for RLIMIT_MEMLOCK?

[Arjan van de Ven]

`
> 
> 1. What is the reason we're having special treatment
>    for the super-user here?

it's quite common to allow root (or more specific, the right capability)
to override rlimits. Many such security check behave that way so it's
only "just" to treat this one like that as well.


> 2. Why is it the opposite of what 2.6.8.1 and earlier did?

the earlier behavior didn't really make sense, and gave cause to
multimedia apps running as root only to be able to mlock etc etc. Now
this can be dynamically controlled instead.


> 4. Is the default hard limit of 32 kB initialized by the kernel or

the kernel has a relatively low default. The reason is simple: allow too
much mlock and the user can DoS the machine too easy. The kernel default
should be safe, the admin / distro can very easily override anyway.

You may ask: why is it not zero?
It is very useful for many things to have a "small" mlock area. gpg, ssh
and basically anything that works with keys and passwords. Small
relative to the other resources such a process takes (eg kernel stacks
etc).

Re: Rationale for RLIMIT_MEMLOCK?

[Matthias Andree]

On Mon, 23 Jan 2006, Arjan van de Ven wrote:

> `
> > 
> > 1. What is the reason we're having special treatment
> >    for the super-user here?
> 
> it's quite common to allow root (or more specific, the right capability)
> to override rlimits. Many such security check behave that way so it's
> only "just" to treat this one like that as well.

Why is RLIMIT_MEMLOCK special enough to warrant special treatment like
this? The right capability should be able to override with setrlimit(2)
anyways, right?

> > 2. Why is it the opposite of what 2.6.8.1 and earlier did?
> 
> the earlier behavior didn't really make sense, and gave cause to
> multimedia apps running as root only to be able to mlock etc etc. Now
> this can be dynamically controlled instead.

Quoting the manpage: "In Linux kernels before 2.6.9, this limit
controlled the amount of memory that could be locked by a privileged
process."

This is nonsense, and it appears as though 2.6.8 and earlier didn't
apply the limit to unprivileged processes. Should the behavior stay as
inconsistent as it's now, I'd suggest to reword this to "...before
2.6.9, this limit controlled the amount of memory that could be locked
by /any/ process." or something even better if someone can think of
such. (manpages maintainer Cc'd)

> > 4. Is the default hard limit of 32 kB initialized by the kernel or
> 
> the kernel has a relatively low default. The reason is simple: allow too
> much mlock and the user can DoS the machine too easy. The kernel default
> should be safe, the admin / distro can very easily override anyway.

This doesn't appear to happen for SUSE 10.0, which causes trouble with
some of the "multimedia apps" BTW... apparently the limit was lowered at
the same time as the root restrictions were relaxed.

Such changes in behavior aren't adequate for 2.6.X, there are way too
many applications that can't be bothered to check the patchlevel of the
kernel, and it's totally unintuitive to users, too. Aside from the fact
that most distros have settled on one kernel.

> You may ask: why is it not zero?

No, I'm not doing that. I rather wonder why it's so low, or whom a certain
percentage such as RAM >> 5 (that's 3.125 %) would hurt. Allowing
unlimited memory allocation while at the same time allowing only 32 kB
of mlock()ed memory seems disproportionate to me.

-- 
Matthias Andree

Re: Rationale for RLIMIT_MEMLOCK?

[Arjan van de Ven]

> > > 4. Is the default hard limit of 32 kB initialized by the kernel or
> > 
> > the kernel has a relatively low default. The reason is simple: allow too
> > much mlock and the user can DoS the machine too easy. The kernel default
> > should be safe, the admin / distro can very easily override anyway.
> 
> This doesn't appear to happen for SUSE 10.0, which causes trouble with
> some of the "multimedia apps" BTW... apparently the limit was lowered at
> the same time as the root restrictions were relaxed.

yes the behavior is like this

                 root                non-root
before        about half of ram      nothing
after         all of ram             by default small, increasable


> Such changes in behavior aren't adequate for 2.6.X, there are way too
> many applications that can't be bothered to check the patchlevel of the
> kernel, and it's totally unintuitive to users, too. 

there is NO fundamental change here other than a *general* relaxing.
This is important to note: Apps that could mlock before STILL can mlock.
Only apps that would depend on mlock failing with a security check, and
only those who do small portions, break now because suddenly the mlock
succeeds. Big deal... those would have broken when run as root already

> No, I'm not doing that. I rather wonder why it's so low, or whom a certain
> percentage such as RAM >> 5 (that's 3.125 %) would hurt. A

because it's generally a PER PROCESS limit, so fork 60 times and kaboom
things explode. (You can argue  you can forkbomb anyway, but that's
where the process count rlimit comes in)

> Allowing
> unlimited memory allocation while at the same time allowing only 32 kB
> of mlock()ed memory seems disproportionate to me.

it's not. Normal memory is swapable. And thus a far less rare commodity
than precious pinned down memory.

What application do you have in mind that broke by this relaxing of
rules?

Re: Rationale for RLIMIT_MEMLOCK?

[Matthias Andree]

On Mon, 23 Jan 2006, Arjan van de Ven wrote:

> yes the behavior is like this
> 
>                  root                non-root
> before        about half of ram      nothing
> after         all of ram             by default small, increasable
> [...]
> What application do you have in mind that broke by this relaxing of
> rules?

This is not something I'd like to disclose here yet.

It is an application that calls mlockall(MCL_CURRENT|MCL_FUTURE) and
apparently copes with mlockall() returning EPERM (or doesn't even try
it) but can apparently NOT cope with valign() tripping over mmap() ==
-1/EAGAIN.

The relevant people are Bcc:d.

-- 
Matthias Andree

Re: Rationale for RLIMIT_MEMLOCK?

[Arjan van de Ven]

On Mon, 2006-01-23 at 19:01 +0100, Matthias Andree wrote:
> On Mon, 23 Jan 2006, Arjan van de Ven wrote:
> 
> > yes the behavior is like this
> > 
> >                  root                non-root
> > before        about half of ram      nothing
> > after         all of ram             by default small, increasable
> > [...]
> > What application do you have in mind that broke by this relaxing of
> > rules?
> 
> This is not something I'd like to disclose here yet.
> 
> It is an application that calls mlockall(MCL_CURRENT|MCL_FUTURE) and
> apparently copes with mlockall() returning EPERM 

hmm... curious that mlockall() succeeds with only a 32kb rlimit....

Re: Rationale for RLIMIT_MEMLOCK?

[Matthias Andree]

On Mon, 23 Jan 2006, Arjan van de Ven wrote:

> hmm... curious that mlockall() succeeds with only a 32kb rlimit....

It's quite obvious with the seteuid() shuffling behind the scenes of the
app, for the mlockall() runs with euid==0, and the later mmap() with euid!=0.

Clearly the application should do both with the same privilege or raise
the RLIMIT_MEMLOCK while running with privileges.

The question that's open is one for the libc guys: malloc(), valloc()
and others seem to use mmap() on some occasions (for some allocation
sizes) - at least malloc/malloc.c comments as of 2.3.4 suggest so -, and
if this isn't orthogonal to mlockall() and set[e]uid() calls, the glibc
is pretty deeply in trouble if the code calls mlockall(MLC_FUTURE) and
then drops privileges.

The function in question appears to be valloc() with glibc 2.3.5.

In this light, mlockall(MCL_FUTURE) is pretty useless, since there is no
way to undo MCL_FUTURE without unlocking all pages at the same time.
Particularly so for setuid apps...

I'm asking the Bcc'd gentleman to reconsider mlockall() and perhaps use
explicit mlock() instead.

-- 
Matthias Andree

Re: Rationale for RLIMIT_MEMLOCK?

[Joerg Schilling]

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

> On Mon, 23 Jan 2006, Arjan van de Ven wrote:
>
> > hmm... curious that mlockall() succeeds with only a 32kb rlimit....
>
> It's quite obvious with the seteuid() shuffling behind the scenes of the
> app, for the mlockall() runs with euid==0, and the later mmap() with euid!=0.
>
> Clearly the application should do both with the same privilege or raise
> the RLIMIT_MEMLOCK while running with privileges.
>
> The question that's open is one for the libc guys: malloc(), valloc()
> and others seem to use mmap() on some occasions (for some allocation
> sizes) - at least malloc/malloc.c comments as of 2.3.4 suggest so -, and
> if this isn't orthogonal to mlockall() and set[e]uid() calls, the glibc
> is pretty deeply in trouble if the code calls mlockall(MLC_FUTURE) and
> then drops privileges.

If the behavior described by Matthias is true for current Linuc kernels,
then there is a clean bug that needs fixing.

If the Linux kernel is not willing to accept the contract by 
mlockall(MLC_FUTURE), then it should now accept the call at all.

In our case, the kernel did accept the call to mlockall(MLC_FUTURE), but later 
ignores this contract. This bug should be fixed.

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

Re: Rationale for RLIMIT_MEMLOCK?

[Lee Revell]

On Mon, 2006-01-23 at 20:38 +0100, Joerg Schilling wrote:
> Matthias Andree <matthias.andree@gmx.de> wrote:
> 
> > On Mon, 23 Jan 2006, Arjan van de Ven wrote:
> >
> > > hmm... curious that mlockall() succeeds with only a 32kb rlimit....
> >
> > It's quite obvious with the seteuid() shuffling behind the scenes of the
> > app, for the mlockall() runs with euid==0, and the later mmap() with euid!=0.
> >
> > Clearly the application should do both with the same privilege or raise
> > the RLIMIT_MEMLOCK while running with privileges.
> >
> > The question that's open is one for the libc guys: malloc(), valloc()
> > and others seem to use mmap() on some occasions (for some allocation
> > sizes) - at least malloc/malloc.c comments as of 2.3.4 suggest so -, and
> > if this isn't orthogonal to mlockall() and set[e]uid() calls, the glibc
> > is pretty deeply in trouble if the code calls mlockall(MLC_FUTURE) and
> > then drops privileges.
> 
> If the behavior described by Matthias is true for current Linuc kernels,
> then there is a clean bug that needs fixing.
> 
> If the Linux kernel is not willing to accept the contract by 
> mlockall(MLC_FUTURE), then it should now accept the call at all.
> 
> In our case, the kernel did accept the call to mlockall(MLC_FUTURE), but later 
> ignores this contract. This bug should be fixed.

Joerg,

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.

This will take a while to make it into distros as it requires changes to
PAM and glibc in addition to the kernel.

Lee

CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Matthias Andree]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Lee Revell]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Joerg Schilling]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Lee Revell]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Lee Revell]

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 

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Joerg Schilling]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Joerg Schilling]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Jan Engelhardt]

[-- 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/

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Joerg Schilling]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Jens Axboe]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Jan Engelhardt]

>> 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
-- 

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Jens Axboe]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Jens Axboe]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Joerg Schilling]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Jens Axboe]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Joerg Schilling]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Jens Axboe]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Lee Revell]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Jan Engelhardt]

(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
-- 

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Vadim Lobanov]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Gene Heskett]

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.

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Vadim Lobanov]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Pavel Machek]

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!

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Luke-Jr]

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?

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Jan Engelhardt]

[-- 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
-- 

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Joerg Schilling]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Luke-Jr]

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.

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Joerg Schilling]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Matthias Andree]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Peter Read]

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/
>

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Joerg Schilling]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Matthias Andree]

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

Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Luke-Jr]

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.