Re: Samsung DVD writer.
Bill Davidsen
> scdb...@gmx.net wrote:
>
>
>> Joerg Schilling wrote:
>>
>>> I see no relation to cdrecord......
>>>
>> There seems to be rather a relation to drive weirdology.
>>
>> A GET CONFIGURATION command should succeed if the
>> drive is ready to do any work.
>> "Unsupported ATAPI command 0x46" looks much like
>> a message from operating system resp. a ATA controller.
>>
>
> No, it looks like a typical badly understandable error message
> from growisofs...
>
>
>> Do you have an opportunity to connect the drive
>> to a computer with Linux ? Would dvd+rw-mediainfo
>> fail there too ?
>>
>
> This does not make sense :-(
>
> If you have the opportinits to connect to a computer with
> Solaris, you may verify whether there is a Linux driver bug.
>
> If you like to see an error message that is meaningful, get a
> recent cdrtools
>
> ftp://ftp.berlios.de/pub/cdrecord/alpha/
>
> and call cdrecord -prcap and cdrecord -minfo as root or install
> cdrecord as root.
>
Haven't you fixed the problem of requiring root YET?!! I don't expect
you to fix it on Linux, but I would have thought BSD would work.
--
bill davidsen <davi...@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
--
To UNSUBSCRIBE, email to cdwrite...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@other.debian.org
Joerg Schilling
> > If you like to see an error message that is meaningful, get a
> > recent cdrtools
> >
> > ftp://ftp.berlios.de/pub/cdrecord/alpha/
> >
> > and call cdrecord -prcap and cdrecord -minfo as root or install
> > cdrecord as root.
> >
>
> Haven't you fixed the problem of requiring root YET?!! I don't expect
> you to fix it on Linux, but I would have thought BSD would work.
I cannot "fix" this as this is a Linux kernel requirement.
Cdrecord works perfectly without root if you are on Solaris
but Solaris offers a _complete_ fine grained privileges implementation
that Linux is still missing.
see "man privileges"
Before Linux-2.6.8.1, *) you could in theory write CDs/DVDs without root
privileges is you did not care about coasters that are a result of
buffer underruns. With Linux-2.6.8.1 the Linux SCSI kernel interface
has been broken by an inexperienced programmer that claimed to fix
a security problem which has been introduced some time before _without_
breking the kernel interface ;-)
Without root privileges, cdrecord is not able to send all needed SCSI commands
on a recent Linux kernel. The fact that _some_ SCSI commands may still be send
without root provileges and the fact that cdrecord tries to self adopt to the
features of the drive, often confuses novice-programmers like the Debian
package maintainers for cdrecord.....don't believe these inexpecienced people.
*) With early Linux-2.4.x versions this did only work if you did play with
device node permissions and did give up the security of your installation.
Decent kernel implementations would not allow this as it is a security
risk.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Norbert Preining
> buffer underruns. With Linux-2.6.8.1 the Linux SCSI kernel interface
> has been broken by an inexperienced programmer that claimed to fix
There we go again ...
> features of the drive, often confuses novice-programmers like the Debian
> package maintainers for cdrecord.....don't believe these inexpecienced people.
Please stop discrediting Debian maintainers with wrong accusations. We
have heard this too many times.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining <prei...@logic.at> Università di Siena
Debian Developer <prei...@debian.org> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
GILDERSOME (adj.) Descriptive of a joke someone tells you which starts
well, but which becomes so embellished in the telling that you start
to weary of it after scarcely half an hour.
--- Douglas Adams, The Meaning of Liff
Joerg Schilling
> > features of the drive, often confuses novice-programmers like the Debian
> > package maintainers for cdrecord.....don't believe these inexpecienced people.
>
> Please stop discrediting Debian maintainers with wrong accusations. We
> have heard this too many times.
We all know that you are an _uninformed_ troll, there is no need to prove this
over and over again....
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Matthias Andree
<Joerg.S...@fokus.fraunhofer.de> wrote:
> Bill Davidsen <davi...@tmr.com> wrote:
>
>> > If you like to see an error message that is meaningful, get a
>> > recent cdrtools
>> >
>> > ftp://ftp.berlios.de/pub/cdrecord/alpha/
>> >
>> > and call cdrecord -prcap and cdrecord -minfo as root or install
>> > cdrecord as root.
>> >
>>
>> Haven't you fixed the problem of requiring root YET?!! I don't expect
>> you to fix it on Linux, but I would have thought BSD would work.
>
> I cannot "fix" this as this is a Linux kernel requirement.
Bill asked about BSD *ONLY*.
So will you answer his question or are you - as usual - unable to, because
you still can't get your feelings under control to an extent of discussing
in a professional manner?
--
Matthias Andree
Bill Davidsen
>>> If you like to see an error message that is meaningful, get a
>>> recent cdrtools
>>>
>>> ftp://ftp.berlios.de/pub/cdrecord/alpha/
>>>
>>> and call cdrecord -prcap and cdrecord -minfo as root or install
>>> cdrecord as root.
>>> =20
>> Haven't you fixed the problem of requiring root YET?!! I don't expect =
>> you to fix it on Linux, but I would have thought BSD would work.
>> =20
>
> I cannot "fix" this as this is a Linux kernel requirement.
>
> =20
Hogwash. growisofs works without root, therefore you either choose to=20
claim it is a Linux problem, or you don't understand how to fix it.=20
Moreover, the hacked version of cdrecord which comes with Fedora works=20
without root, although it's a bit old.
> Cdrecord works perfectly without root if you are on Solaris
> but Solaris offers a _complete_ fine grained privileges implementation
> that Linux is still missing.
>
> see "man privileges"
>
>
> Before Linux-2.6.8.1, *) you could in theory write CDs/DVDs without roo=
t
> privileges is you did not care about coasters that are a result of
> buffer underruns. With Linux-2.6.8.1 the Linux SCSI kernel interface
> has been broken by an inexperienced programmer that claimed to fix
> a security problem which has been introduced some time before _without_=
> breking the kernel interface ;-)
>
> Without root privileges, cdrecord is not able to send all needed SCSI c=
ommands
> on a recent Linux kernel. The fact that _some_ SCSI commands may still =
be send
> without root provileges and the fact that cdrecord tries to self adopt =
to the=20
> features of the drive, often confuses novice-programmers like the Debia=
n=20
> package maintainers for cdrecord.....don't believe these inexpecienced =
people.
>
>
>
> *) With early Linux-2.4.x versions this did only work if you did play w=
ith
> device node permissions and did give up the security of your installati=
on.
> Decent kernel implementations would not allow this as it is a security
> risk.
>
>
> J=F6rg
>
> =20
--=20
Matthias Andree
> Hogwash. growisofs works without root, therefore you either choose to
> claim it is a Linux problem, or you don't understand how to fix
> it. Moreover, the hacked version of cdrecord which comes with Fedora
> works without root, although it's a bit old.
I've debugged more than one of the numerous libscg bugs last year, which
all were either in the categories "standing in your own way",
"artificial barriers" and "assumptions not covered by any standard", and
often, just rearranging the execution sequence or removing superfluous
differences would fix issues.
None of the fixes or debugging with detailed fix instructions I offered
to J=F6rg made the code AFAICS, and his rants last year also scared people
away who were originally set to fix one of the Linux rlimit regressions.
(I suggested a workaround, J=F6rg was aware of it, but didn't take it for
unknown reasons, he wouldn't say. As usual :-().
This however is incompatible with J=F6rg's behavior, he isn't actually
interested in getting his software portable, but rather "invests" his
time into flamewar and offenses -- as this thread demonstrated with the
long anti-Linux pro-Solaris rant when he was asked about non-root BSD
usage.
--=20
Matthias Andree
Joerg Schilling
> >>> If you like to see an error message that is meaningful, get a
> >>> recent cdrtools
> >>>
> >>> ftp://ftp.berlios.de/pub/cdrecord/alpha/
> >>>
> >>> and call cdrecord -prcap and cdrecord -minfo as root or install
> >>> cdrecord as root.
> >>>
> >>>
> >> Haven't you fixed the problem of requiring root YET?!! I don't expect
> >> you to fix it on Linux, but I would have thought BSD would work.
> >>
> >
> > I cannot "fix" this as this is a Linux kernel requirement.
> >
> >
> Hogwash. growisofs works without root, therefore you either choose to
> claim it is a Linux problem, or you don't understand how to fix it.
Do you like a decent discussion or do you like to be one of the uninformed
people who participate in the braindead FUD against cdrtools?
If you have no clue on the background, you should listen to people like me who
know what they are talking about.... You are listening to the wrong people.
> Moreover, the hacked version of cdrecord which comes with Fedora works
> without root, although it's a bit old.
Read the text of my last mail and try to understand _why_ _some_ people might
believe that cdrecord is able to work under _some_ _conditions_.
I am not sure about what limited services growisofs provides. I did see enough
logs from cdrecord that verify the fact that Linux does not allow cdrecord to
work correctly under all conditions. This is because Linux does not allow all
the SCSI commands cdrecord needs for it's work unless cdrecord runs with root
privileges.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
linuxpiewie
> I did see
> enough logs from cdrecord that verify the fact that Linux does not allow
> cdrecord to work correctly under all conditions. This is because Linux does
> not allow all the SCSI commands cdrecord needs for it's work unless
> cdrecord runs with root privileges.
>
Thomas
Joerg Schilling
> On Sunday 01 April 2007 21:56, Joerg Schilling wrote:
> > I did see
> > enough logs from cdrecord that verify the fact that Linux does not allow
> > cdrecord to work correctly under all conditions. This is because Linux does
> > not allow all the SCSI commands cdrecord needs for it's work unless
> > cdrecord runs with root privileges.
> >
> Can you please tell me what commands are affected by the root problem?
All vendor unique commands, such as for Yamaha/Plextor specific functions.
All commands for old (pre-MMC) writers.
Some MMC commands needed for DVD writing, but here I do not remember the
commands.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bill Davidsen
--------------050406070909000906010506
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Joerg Schilling wrote:
> Bill Davidsen <davi...@tmr.com> wrote:
>
>
>>>>> If you like to see an error message that is meaningful, get a
>>>>> recent cdrtools
>>>>>
>>>>> ftp://ftp.berlios.de/pub/cdrecord/alpha/
>>>>>
>>>>> and call cdrecord -prcap and cdrecord -minfo as root or install
>>>>> cdrecord as root.
>>>>>
>>>>>
>>>>>
>>>> Haven't you fixed the problem of requiring root YET?!! I don't expect
>>>> you to fix it on Linux, but I would have thought BSD would work.
>>>>
>>>>
>>> I cannot "fix" this as this is a Linux kernel requirement.
>>>
>>>
>>>
>> Hogwash. growisofs works without root, therefore you either choose to
>> claim it is a Linux problem, or you don't understand how to fix it.
>>
>
> Do you like a decent discussion or do you like to be one of the uninformed
> people who participate in the braindead FUD against cdrtools?
>
> If you have no clue on the background, you should listen to people like me who
> know what they are talking about.... You are listening to the wrong people.
>
>
You said it didn't work right unless run as root. You said it, you
quoted yourself, you advised to run as root. See above.
Now if I'm listening to the wrong people, they are you.
>> Moreover, the hacked version of cdrecord which comes with Fedora works
>> without root, although it's a bit old.
>>
>
> Read the text of my last mail and try to understand _why_ _some_ people might
> believe that cdrecord is able to work under _some_ _conditions_.
>
> I am not sure about what limited services growisofs provides. I did see enough
> logs from cdrecord that verify the fact that Linux does not allow cdrecord to
> work correctly under all conditions. This is because Linux does not allow all
> the SCSI commands cdrecord needs for it's work unless cdrecord runs with root
> privileges.
>
The "limited services" include burning optical media, something cdrecord
won't do on Linux. And as for "all the SCSI commands cdrecord needs,"
why does it need more than other burning software? If you can't run
realtime priority (no other software needs that), or lock the unit, or
sprinkle the media with holy water, NO ONE ELSE NEEDS TO DO THAT! You
have let the desire for trivial unnecessary flourishes blind you to the
fact that people run the software to burn optical media.
If you feel you want to whine about no being able to these things, add
text to your meaningless warnings, or better yet check for a
".stopwhining" file in the home directory and don't bother to list all
the largely unnecessary things you can't do.
--
Bill Davidsen <davi...@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
--------------050406070909000906010506
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Joerg Schilling wrote:
<blockquote
cite="mid46100e6e.NkrOwZTy+x%2F8z5c9%25Joerg....@fokus.fraunhofer.de"
type="cite">
<pre wrap="">Bill Davidsen <a class="moz-txt-link-rfc2396E" href="mailto:davi...@tmr.com"><davi...@tmr.com></a> wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">If you like to see an error message that is meaningful, get a
recent cdrtools
<a class="moz-txt-link-freetext" href="ftp://ftp.berlios.de/pub/cdrecord/alpha/">ftp://ftp.berlios.de/pub/cdrecord/alpha/</a>
and call cdrecord -prcap and cdrecord -minfo as root or install
cdrecord as root.
</pre>
</blockquote>
<pre wrap="">Haven't you fixed the problem of requiring root YET?!! I don't expect
you to fix it on Linux, but I would have thought BSD would work.
</pre>
</blockquote>
<pre wrap="">I cannot "fix" this as this is a Linux kernel requirement.
</pre>
</blockquote>
<pre wrap="">Hogwash. growisofs works without root, therefore you either choose to
claim it is a Linux problem, or you don't understand how to fix it.
</pre>
</blockquote>
<pre wrap=""><!---->
Do you like a decent discussion or do you like to be one of the uninformed
people who participate in the braindead FUD against cdrtools?
If you have no clue on the background, you should listen to people like me who
know what they are talking about.... You are listening to the wrong people.
</pre>
</blockquote>
You said it didn't work right unless run as root. You said it, you
quoted yourself, you advised to run as root. See above.<br>
<br>
Now if I'm listening to the wrong people, they are you.<br>
<blockquote
cite="mid46100e6e.NkrOwZTy+x%2F8z5c9%25Joerg....@fokus.fraunhofer.de"
type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">Moreover, the hacked version of cdrecord which comes with Fedora works
without root, although it's a bit old.
</pre>
</blockquote>
<pre wrap=""><!---->
Read the text of my last mail and try to understand _why_ _some_ people might
believe that cdrecord is able to work under _some_ _conditions_.
I am not sure about what limited services growisofs provides. I did see enough
logs from cdrecord that verify the fact that Linux does not allow cdrecord to
work correctly under all conditions. This is because Linux does not allow all
the SCSI commands cdrecord needs for it's work unless cdrecord runs with root
privileges.
</pre>
</blockquote>
<br>
The "limited services" include burning optical media, something
cdrecord won't do on Linux. And as for "all the SCSI commands cdrecord
needs," why does it need more than other burning software? If you can't
run realtime priority (no other software needs that), or lock the unit,
or sprinkle the media with holy water, NO ONE ELSE NEEDS TO DO THAT!
You have let the desire for trivial unnecessary flourishes blind you to
the fact that people run the software to burn optical media.<br>
<br>
If you feel you want to whine about no being able to these things, add
text to your meaningless warnings, or better yet check for a
".stopwhining" file in the home directory and don't bother to list all
the largely unnecessary things you can't do.<br>
<br>
<pre class="moz-signature" cols="72">--
Bill Davidsen <a class="moz-txt-link-rfc2396E" href="mailto:davi...@tmr.com"><davi...@tmr.com></a>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
</pre>
</body>
</html>
--------------050406070909000906010506--
Joerg Schilling
> >> Hogwash. growisofs works without root, therefore you either choose to
> >> claim it is a Linux problem, or you don't understand how to fix it.
> >>
> >
> > Do you like a decent discussion or do you like to be one of the uninformed
> > people who participate in the braindead FUD against cdrtools?
> >
> > If you have no clue on the background, you should listen to people like me who
> > know what they are talking about.... You are listening to the wrong people.
> >
> >
> You said it didn't work right unless run as root. You said it, you
> quoted yourself, you advised to run as root. See above.
Let us continue this after you are no longer confused.....
> The "limited services" include burning optical media, something cdrecord
> won't do on Linux. And as for "all the SCSI commands cdrecord needs,"
Could you please stop your FUD?
If you can't, please stay away!
I am willing to discuss things with any person who is interested in a real
discussion that is not mased in repeating FUD from uninformed people.
I did explain which SCSI commands are currently blocked by the Linux kernel
and will probably never be available again without root privs.
If other authors prefer to write hacky software instead of asking the drive
usig official MMC SCSI commands, I am willing to accept this but this is
not the way I write software.
If you like to know who "the wrong people" are, I may give you a list of
people who are known to write only FUD and uninformed nonsense during the
past 2 years:
- Eduard Bloch
- Matthias Andree
- Norbert Preining
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Norbert Preining
> - Eduard Bloch
> - Matthias Andree
> - Norbert Preining
Hey I am in great companion, didn't know how to manage this. Well,
thanks a lot Jörg, I consider this an honor to be listed by you in this
way!
Norbert
(going out for an apperitivo!)
-------------------------------------------------------------------------------
Dr. Norbert Preining <prei...@logic.at> Università di Siena
Debian Developer <prei...@debian.org> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
SILESIA (n. medical)
The inability to remember, at the critical moment, which is the better
side of a boat to be seasick off.
--- Douglas Adams, The Meaning of Liff
Bill Davidsen
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Joerg Schilling wrote:
> linuxpiewie <linux...@web.de> wrote:
>
>
>> On Sunday 01 April 2007 21:56, Joerg Schilling wrote:
>>
>>> I did see
>>> enough logs from cdrecord that verify the fact that Linux does not allow
>>> cdrecord to work correctly under all conditions. This is because Linux does
>>> not allow all the SCSI commands cdrecord needs for it's work unless
>>> cdrecord runs with root privileges.
>>>
>>>
>> Can you please tell me what commands are affected by the root problem?
>>
>
> All vendor unique commands, such as for Yamaha/Plextor specific functions.
>
>
I believe this is true, but just writing a disk is hardly vendor specific.
> All commands for old (pre-MMC) writers.
>
>
That is clearly going to be true.
> Some MMC commands needed for DVD writing, but here I do not remember the
> commands.
>
On this, since other software writes disks, I would classify these
commands as "desirable" rather than "required." Feel free to list
commands you feel are necessary to the basic functionality if you can
identify any.
Note: I completely agree that some commands are blocked which would be
desirable, but the general case, "put data on a disk" can be done
without root if a standard MMC device is being used.
--
Bill Davidsen <davi...@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
--------------080500090306050301040707
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Joerg Schilling wrote:
<blockquote
cite="mid4610383c.Xgvt4bmsRL7AdkZ1%25Joerg....@fokus.fraunhofer.de"
type="cite">
<pre wrap="">linuxpiewie <a class="moz-txt-link-rfc2396E" href="mailto:linux...@web.de"><linux...@web.de></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Sunday 01 April 2007 21:56, Joerg Schilling wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I did see
enough logs from cdrecord that verify the fact that Linux does not allow
cdrecord to work correctly under all conditions. This is because Linux does
not allow all the SCSI commands cdrecord needs for it's work unless
cdrecord runs with root privileges.
</pre>
</blockquote>
<pre wrap="">Can you please tell me what commands are affected by the root problem?
</pre>
</blockquote>
<pre wrap=""><!---->
All vendor unique commands, such as for Yamaha/Plextor specific functions.
</pre>
</blockquote>
I believe this is true, but just writing a disk is hardly vendor
specific.<br>
<blockquote
cite="mid4610383c.Xgvt4bmsRL7AdkZ1%25Joerg....@fokus.fraunhofer.de"
type="cite">
<pre wrap="">All commands for old (pre-MMC) writers.
</pre>
</blockquote>
That is clearly going to be true.<br>
<blockquote
cite="mid4610383c.Xgvt4bmsRL7AdkZ1%25Joerg....@fokus.fraunhofer.de"
type="cite">
<pre wrap="">Some MMC commands needed for DVD writing, but here I do not remember the
commands.
</pre>
</blockquote>
On this, since other software writes disks, I would classify these
commands as "desirable" rather than "required." Feel free to list
commands you feel are necessary to the basic functionality if you can
identify any.<br>
<br>
Note: I completely agree that some commands are blocked which would be
desirable, but the general case, "put data on a disk" can be done
without root if a standard MMC device is being used.<br>
<pre class="moz-signature" cols="72">--
Bill Davidsen <a class="moz-txt-link-rfc2396E" href="mailto:davi...@tmr.com"><davi...@tmr.com></a>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
</pre>
</body>
</html>
--------------080500090306050301040707--
Joerg Schilling
> > All vendor unique commands, such as for Yamaha/Plextor specific functions.
> >
> >
> I believe this is true, but just writing a disk is hardly vendor specific.
It seems that you did not understand the problem. See below also.
> > All commands for old (pre-MMC) writers.
> >
> >
> That is clearly going to be true.
Well at least one item where you are not trying to counter.
> > Some MMC commands needed for DVD writing, but here I do not remember the
> > commands.
> >
> On this, since other software writes disks, I would classify these
> commands as "desirable" rather than "required." Feel free to list
> commands you feel are necessary to the basic functionality if you can
> identify any.
You may claasify for yourself whatever you like, but note some important
things:
I am the author of cdrtools and I decide how to write cdrecord. I do not
write hacks as other aothors may do but I follow the MMC standard and I
decide which commands are needed for a useful interaction with the drive.
I am not going to align the way I write cdrecord with the ideas of
some silly people who try try to make Linux hard to use.
> Note: I completely agree that some commands are blocked which would be
> desirable, but the general case, "put data on a disk" can be done
> without root if a standard MMC device is being used.
There is no need to discuss this. The important facts to learn from me is:
I write cdrecord in a way that allows me to support as many features as
possible.
I write cdrecord in a way that allows me to know as much on the drive in
advance as possible.
If the way Linux is implemented forces me to run cdrecord with root
privileges in order to avoid Linux blocking some of the commands I use,
then root privileges are _the_ _intended_ _way_ to run cdrecord on Linux.
If some people tell you that cdrecord runs without root privileges although
they have been informed about the constraints, these people are just idiots and
should be ignored.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
scdb...@gmx.net
Joerg Schilling:
> I do not
> write hacks as other aothors may do but I follow the MMC standard
Just for the records:
libburn is developed according to MMC and i am not aware of
any serious deviations from MMC in dvd+rw-tools either.
libburn still supports some pre-MMC-5 legacies, like mode
page 2Ah "CD/DVD Capabilities & Mechanical Status Page".
In general we handle CD according to MMC-3 with an eye on
MMC-1, DVD are handled according to MMC-5 without much
legacy support intended.
There is no support intended for pre-MMC-1 burners.
Sorry for for any collector of antique IT equipment.
Have a nice day :)
Thomas
Dave Platt
> There is no need to discuss this. The important facts to learn from me is:
>
> I write cdrecord in a way that allows me to support as many features as
> possible.
>
> I write cdrecord in a way that allows me to know as much on the drive in
> advance as possible.
Jörg,
Would you be willing to provide a specific and complete list
(e.g. in a text file, as part of the cdrtools distribution) of
the set of SCSI commands that you consider to be necessary
and/or desireable for cdrtools? If the commands were listed
all in one place, it would be much easier for people (Linux kernel
maintainers, non-Linux kernel people, and J. Random Kibitzers)
to do a proper security analysis, and then (as necessary) make
a clean decision as to which commands are truly safe for non-root
write access and which may not be.
This list could either be done by enumerating the commands which
are necessary, or could be done by saying "All of the MMC-3 commands,
except for the following", or somewhere in between. The critical
thing would be to have a fully-described list of the commands,
independent of the current source-code implementation of
cdrtools or any other software package.
In looking at the Linux code which implements the security
rules, I can see at least two things which could be done, and
a third might be worthwhile:
[1] The restrictions are implemented in one way in the /dev/sg
generic SCSI driver (older code), and another way in the
general-purpose block-device driver (newer code).
It would seem to make good sense to factor this code out,
and have just a single implementation (probably based on the
newer code, which appears to be more flexible and more
MMC-3-friendly).
[2] The list of MMC-3 commands allowed for non-root write access
in the block device driver might be expanded.
[3] The list of commands might be made extensible at run time,
possibly on a per-device basis. This might be done via the
Linux /proc or /sys interfaces. The built-in list could be used
in most cases, but the individual system owner could extend it
if a particular drive needed a drive-specific command for
full-featured operation.
Bill Davidsen
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
J=F6rg
Dave Platt wrote:
>> There is no need to discuss this. The important facts to learn from me=
is:
>>
>> I write cdrecord in a way that allows me to support as many features a=
s=20
>> possible.
>>
>> I write cdrecord in a way that allows me to know as much on the drive =
in
>> advance as possible.
>> =20
>
> J=F6rg,
>
> Would you be willing to provide a specific and complete list=20
> (e.g. in a text file, as part of the cdrtools distribution) of
> the set of SCSI commands that you consider to be necessary
> and/or desireable for cdrtools? If the commands were listed
> all in one place, it would be much easier for people (Linux kernel
> maintainers, non-Linux kernel people, and J. Random Kibitzers)
> to do a proper security analysis, and then (as necessary) make
> a clean decision as to which commands are truly safe for non-root
> write access and which may not be.
>
> =20
I will venture a guess that the answer will be that as usual the answer=20
will be one or more of (a) Linux developers hate me and wouldn't do it=20
anyway, (b) you can get it from me source code, or (c) if anyone was as=20
smart and wonderful as J=F6rg they wouldn't have to be told.
I've given up being polite and reasonable with J=F6rg, he's smart enough =
to write code that works, everyone else has.
> This list could either be done by enumerating the commands which
> are necessary, or could be done by saying "All of the MMC-3 commands,
> except for the following", or somewhere in between. The critical
> thing would be to have a fully-described list of the commands,
> independent of the current source-code implementation of
> cdrtools or any other software package.
>
> In looking at the Linux code which implements the security
> rules, I can see at least two things which could be done, and
> a third might be worthwhile:
>
> [1] The restrictions are implemented in one way in the /dev/sg
> generic SCSI driver (older code), and another way in the=20
> general-purpose block-device driver (newer code).
>
> It would seem to make good sense to factor this code out,
> and have just a single implementation (probably based on the
> newer code, which appears to be more flexible and more
> MMC-3-friendly).
> =20
Including the ide-scsi driver here would be desirable as well.
> [2] The list of MMC-3 commands allowed for non-root write access
> in the block device driver might be expanded.
> =20
But would have to have a big quirks file to allow commands in the vendor =
group, which do one thing on one hardware, and something undesirable on=20
other hardware.
> [3] The list of commands might be made extensible at run time,
> possibly on a per-device basis. This might be done via the
> Linux /proc or /sys interfaces. The built-in list could be used
> in most cases, but the individual system owner could extend it
> if a particular drive needed a drive-specific command for
> full-featured operation.
This would be a start, but it doesn't address the real problem, which is =
knowing which commands are safe on which hardware. And other than=20
allowing a more complete subset of MMC commands, that's something which=20
needs to be done at user level, or at least is best done there.
The obvious solution would be to set trusted programs setuid root, but=20
that is carefully blocked, resulting in many thing other than CD burning =
now needing root access. I don't regard that as a step forward.
My suggestion would be to add an ioctl, like SET_SCSI_UNFILTERED, which=20
can only be used as root, and which would allow SCSI commands sent a=20
device to be persistently set unfiltered. At least that lets the boot=20
code set ownership and permissions at boot time, and puts the choice of=20
appropriate access back in the hands of the administrator. It would=20
allow individual group membership or trusted programs setgid to fully=20
access the device. Yes, that implies allowing setgid to work.
I've added lkml to the cc list, there's been enough discussion related=20
to this on that list that I think it's relevant.
--=20
bill davidsen <davi...@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
--------------070500070000090809060301
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<pre wrap="">Jörg</pre>
Dave Platt wrote:
<blockquote cite="midcourier.461...@radagast.org" type="cite">
<blockquote type="cite">
<pre wrap="">There is no need to discuss this. The important facts to learn from me is:
I write cdrecord in a way that allows me to support as many features as
possible.
I write cdrecord in a way that allows me to know as much on the drive in
advance as possible.
</pre>
</blockquote>
<pre wrap=""><!---->
Jörg,
Would you be willing to provide a specific and complete list
(e.g. in a text file, as part of the cdrtools distribution) of
the set of SCSI commands that you consider to be necessary
and/or desireable for cdrtools? If the commands were listed
all in one place, it would be much easier for people (Linux kernel
maintainers, non-Linux kernel people, and J. Random Kibitzers)
to do a proper security analysis, and then (as necessary) make
a clean decision as to which commands are truly safe for non-root
write access and which may not be.
</pre>
</blockquote>
I will venture a guess that the answer will be that as usual the answer
will be one or more of (a) Linux developers hate me and wouldn't do it
anyway, (b) you can get it from me source code, or (c) if anyone was as
smart and wonderful as Jörg they wouldn't have to be told.<br>
<br>
I've given up being polite and reasonable with Jörg, he's smart enough
to write code that works, everyone else has.
<blockquote cite="midcourier.461...@radagast.org" type="cite">
<pre wrap="">This list could either be done by enumerating the commands which
are necessary, or could be done by saying "All of the MMC-3 commands,
except for the following", or somewhere in between. The critical
thing would be to have a fully-described list of the commands,
independent of the current source-code implementation of
cdrtools or any other software package.
In looking at the Linux code which implements the security
rules, I can see at least two things which could be done, and
a third might be worthwhile:
[1] The restrictions are implemented in one way in the /dev/sg
generic SCSI driver (older code), and another way in the
general-purpose block-device driver (newer code).
It would seem to make good sense to factor this code out,
and have just a single implementation (probably based on the
newer code, which appears to be more flexible and more
MMC-3-friendly).
</pre>
</blockquote>
<br>
Including the ide-scsi driver here would be desirable as well.<br>
<blockquote cite="midcourier.461...@radagast.org" type="cite">
<pre wrap="">
[2] The list of MMC-3 commands allowed for non-root write access
in the block device driver might be expanded.
</pre>
</blockquote>
<br>
But would have to have a big quirks file to allow commands in the
vendor group, which do one thing on one hardware, and something
undesirable on other hardware.<br>
<blockquote cite="midcourier.461...@radagast.org" type="cite">
<pre wrap="">
[3] The list of commands might be made extensible at run time,
possibly on a per-device basis. This might be done via the
Linux /proc or /sys interfaces. The built-in list could be used
in most cases, but the individual system owner could extend it
if a particular drive needed a drive-specific command for
full-featured operation.</pre>
</blockquote>
This would be a start, but it doesn't address the real problem, which
is knowing which commands are safe on which hardware. And other than
allowing a more complete subset of MMC commands, that's something which
needs to be done at user level, or at least is best done there.<br>
<br>
The obvious solution would be to set trusted programs setuid root, but
that is carefully blocked, resulting in many thing other than CD
burning now needing root access. I don't regard that as a step forward.<br>
<br>
My suggestion would be to add an ioctl, like SET_SCSI_UNFILTERED, which
can only be used as root, and which would allow SCSI commands sent a
device to be persistently set unfiltered. At least that lets the boot
code set ownership and permissions at boot time, and puts the choice of
appropriate access back in the hands of the administrator. It would
allow individual group membership or trusted programs setgid to fully
access the device. Yes, that implies allowing setgid to work.<br>
<br>
I've added lkml to the cc list, there's been enough discussion related
to this on that list that I think it's relevant.<br>
<pre class="moz-signature" cols="72">--
bill davidsen <a class="moz-txt-link-rfc2396E" href="mailto:davi...@tmr.com"><davi...@tmr.com></a>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
</pre>
</body>
</html>
--------------070500070000090809060301--
Joerg Schilling
> Would you be willing to provide a specific and complete list
> (e.g. in a text file, as part of the cdrtools distribution) of
> the set of SCSI commands that you consider to be necessary
> and/or desireable for cdrtools? If the commands were listed
> all in one place, it would be much easier for people (Linux kernel
> maintainers, non-Linux kernel people, and J. Random Kibitzers)
> to do a proper security analysis, and then (as necessary) make
> a clean decision as to which commands are truly safe for non-root
> write access and which may not be.
I am not sure about your intention...
Whether is real interest and what you expect to change.
If you did look at the source, you did discover that it is writte
in a systematic way and that is is easy to fetch this list as all
SCSI commands are set up via
scmd->cdb.*cdb.cmd = 0x??;
lines.
If you write a simple commad line, you get this for cdrecord:
04 0B 0D 1B 1E 23 25 2B 35 3B 3C 42 43 44 46 4D 51 52 53 54 55 59 5A 5B
5C 5D A1 A6 AA AC AD B6 BB BF C1 C3 C6 C7 CE CF DF E0 E1 E2 E3 E4 E5 E6
E7 E9 EA EB EC ED EE F0 F1 F2 F3 F5 F6 F8 FB
this for readcd:
0B 0D 1B 1E 23 25 28 2B 3 35 3C 42 43 44 46 51 52 53 54 55 59 5A 5B 5C
5D A1 A6 AA AC AD B6 BB BE BF d8 E5
and this list for cdda2waw:
0B 0D 1B 1E 25 28 2B 35 3C 42 43 44 47 51 52 53 54 55 59 5A 5B 5C 5D
A1 A6 AA AD BB be BF C5 d4 d8 E5
> This list could either be done by enumerating the commands which
> are necessary, or could be done by saying "All of the MMC-3 commands,
> except for the following", or somewhere in between. The critical
> thing would be to have a fully-described list of the commands,
> independent of the current source-code implementation of
> cdrtools or any other software package.
>
> In looking at the Linux code which implements the security
> rules, I can see at least two things which could be done, and
> a third might be worthwhile:
>
Do you have some SCSI background?
If you do, then you know that there are a lot of vendor unique commands
that have a different meaning depending on thevendor and that you need to
support these commands if you do not like to stick at a rudimentary device
support level. Cdrtools have a more than 10 year history of supporting
vendor unique functions for the convenience of the users.
> [1] The restrictions are implemented in one way in the /dev/sg
> generic SCSI driver (older code), and another way in the
> general-purpose block-device driver (newer code).
>
> It would seem to make good sense to factor this code out,
> and have just a single implementation (probably based on the
> newer code, which appears to be more flexible and more
> MMC-3-friendly).
First, for a long time Linux did need root privileges in order to send
SCSI commands. The fact that newer Linux version allow to do this without
root privileges is a bug introduced by an inexperienced kernel hacker.
Instead of fixing this obvious bug, a random filter list has been introduced.
Note that the security problem in Linux is still present as the current
implementation allows the backup admin to gain root privileges.
> [2] The list of MMC-3 commands allowed for non-root write access
> in the block device driver might be expanded.
>
> [3] The list of commands might be made extensible at run time,
> possibly on a per-device basis. This might be done via the
> Linux /proc or /sys interfaces. The built-in list could be used
> in most cases, but the individual system owner could extend it
> if a particular drive needed a drive-specific command for
> full-featured operation.
Forget about all these thoughts. Linux will either equire root
privileges for cdrecord or it will allow the backup admin to gain
root privileges.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily