Re: [luau] Duplicating Music CD
The default permission (RH 8.0) for /dev/cdrom is 300. As long as I am
the user, making it 777 does not make any difference in this case.
Ben Beeson wrote:
Aloha,
I haven't played much with this or any other cdripper, but... I recall that
default permissions on my cdrom drive have caused me trouble in the past.
Making the cdrom chmod 777 when combined with an appropriate set of
permissions in the fstab file fixed all my troubles without having to suid
any programs. For my own purposes, this was a better solution than fixing
all the programs. Essentially the only security change I had to worry about
was physical access to the cdrom drive as the software remained the same.
Could this or something similar work for cdparanoia? {I don't have a cd
burner, or I'd try it myself. }
Mele Kalikimaka,
Ben
On Sunday 15 December 2002 03:52 pm, you wrote:
In UNIX, a code is better than a thousand words. The following two
lines of simple code should clearly convey to those in the know the
power of the setuid bit in UNIX/Linux/xBSD.
/bin/chgrp xcdwrite /usr/bin/cdparanoia
/bin/chmod 4710 /usr/bin/cdparanoia
___
LUAU mailing list
[EMAIL PROTECTED]
http://videl.ics.hawaii.edu/mailman/listinfo/luau
Re: [luau] Duplicating Music CD
W. Wayne Liauh wrote:
The default permission (RH 8.0) for /dev/cdrom is 300. As long as I
am the user, making it 777 does not make any difference in this case.
Ben Beeson wrote:
Aloha,
I haven't played much with this or any other cdripper, but... I
recall that default permissions on my cdrom drive have caused me
trouble in the past. Making the cdrom chmod 777 when combined with
an appropriate set of permissions in the fstab file fixed all my
troubles without having to suid any programs. For my own purposes,
this was a better solution than fixing all the programs. Essentially
the only security change I had to worry about was physical access to
the cdrom drive as the software remained the same. Could this or
something similar work for cdparanoia? {I don't have a cd burner, or
I'd try it myself. }
Mele Kalikimaka,
Ben
On Sunday 15 December 2002 03:52 pm, you wrote:
In UNIX, a code is better than a thousand words. The following two
lines of simple code should clearly convey to those in the know the
power of the setuid bit in UNIX/Linux/xBSD.
/bin/chgrp xcdwrite /usr/bin/cdparanoia
/bin/chmod 4710 /usr/bin/cdparanoia
___
LUAU mailing list
[EMAIL PROTECTED]
http://videl.ics.hawaii.edu/mailman/listinfo/luau
___
LUAU mailing list
[EMAIL PROTECTED]
http://videl.ics.hawaii.edu/mailman/listinfo/luau
Re: [luau] Duplicating Music CD
The default permission (RH 8.0) for /dev/cdrom is 300. Since I am the
owner of this file, as long as I am the user, making it 777 does not
make any difference in this case.
Ben Beeson wrote:
Aloha,
I haven't played much with this or any other cdripper, but... I recall that
default permissions on my cdrom drive have caused me trouble in the past.
Making the cdrom chmod 777 when combined with an appropriate set of
permissions in the fstab file fixed all my troubles without having to suid
any programs. For my own purposes, this was a better solution than fixing
all the programs. Essentially the only security change I had to worry about
was physical access to the cdrom drive as the software remained the same.
Could this or something similar work for cdparanoia? {I don't have a cd
burner, or I'd try it myself. }
Mele Kalikimaka,
Ben
Re: [luau] Duplicating Music CD
W. Wayne Liauh wrote: The default permission (RH 8.0) for /dev/cdrom is 300. Oops. 600.
Re: [luau] Duplicating Music CD
In UNIX, a code is better than a thousand words. The following two lines of simple code should clearly convey to those in the know the power of the setuid bit in UNIX/Linux/xBSD. /bin/chgrp xcdwrite /usr/bin/cdparanoia /bin/chmod 4710 /usr/bin/cdparanoia With cdparanoia/xcdroast, I was able to rip a regular audio CD in about 10 minutes (compared to sometimes hours with cdda2wav; however, it must be noted that I have only very limited experience with either program). Thus, conceivably, it should not be too difficult to write a script combining cdparanoia and cdrecord for direct audio copying. W. Wayne Liauh wrote: Very good point(s). Again, I don't think we can discuss the setuid issue without realizing that we are talking about (1) a consumer-oriented desktop, for which there is necessarily a recognizedly lesser level of security that needs to be implemented, and (2) a set of CDROM-associated programs that are designed to have their setuid turned on (i.e., w/o the options that may cause buffer overflow concerns or other known security issues). When an executable file has its SUID bit set, the file's owner owns the resulting process, no matter who launched it. Of course we don't want the SUID bit to be set for every executable program, but sometimes, such as su, sudo as you mentioned, or a printing program such as lpr, this is a necessary evil. OTOH, you are also exactly right on the wrapper script that's setuid to a certian group that has full access to the CDROM and CD Player. In order to run cdparanoia or cdda2wav, you also have me make yourself member of a group called xcdwrite.
Re: [luau] Duplicating Music CD
Aloha,
I haven't played much with this or any other cdripper, but... I recall
that
default permissions on my cdrom drive have caused me trouble in the past.
Making the cdrom chmod 777 when combined with an appropriate set of
permissions in the fstab file fixed all my troubles without having to suid
any programs. For my own purposes, this was a better solution than fixing
all the programs. Essentially the only security change I had to worry about
was physical access to the cdrom drive as the software remained the same.
Could this or something similar work for cdparanoia? {I don't have a cd
burner, or I'd try it myself. }
Mele Kalikimaka,
Ben
On Sunday 15 December 2002 03:52 pm, you wrote:
In UNIX, a code is better than a thousand words. The following two
lines of simple code should clearly convey to those in the know the
power of the setuid bit in UNIX/Linux/xBSD.
/bin/chgrp xcdwrite /usr/bin/cdparanoia
/bin/chmod 4710 /usr/bin/cdparanoia
Re: [luau] Duplicating Music CD
W. Wayne Liauh wrote: Hi Vince- Apparently you have never used xcdroast or grip yourself? What is the most recent version of commercial Linux distribution that you have used? I am asking this question, because you apparently don't really know the heck of what I was talking about. Yes, there are some inherent problems with the setuid facility--anything that deals with root privilege inherently has security problems. But it is well recognized that Linux's setuid facility allows programs to run by ordinary users to make use of the root account in a limited and tightly controlled way. Of course, it is also well noted that if you use setuid shell scripts in a certain shell, they can be entirely insecure. But we are talking about a well-known program, and not a setuid script. I really hate people who mix apples and oranges. OK, I'll clear up a bit of confusion we seem to be having here about the setuid bit. Normally, when you run a program, it gets run as you. This means it has all the same permissions you do, including what you can do on the filesystem. When you run something that has the setuid bit set, it gets run as the user who owns the file (often root). This means that it has all the permissions of that user (if root, total). This is useful for GAINING privilages (su for example) or changing between users (su again, since only root can do setuid). In this case, we're talking about running something as root so it has access to a CD drive. Most programs that are designed to be run setuid immediately drop all capabilities they don't need (Linux is pretty flexible here with POSIX CAPS). The idea is to drop all privilages we can (and carefully audit the secions of code where we do this) and then setuid everythign back over to the user that ran the program (leaving just a few additional programs left, like the ability to edit the shadow password file for passwd). Problems occur with this in two circumstances: A program is setuid that wasn't designed for it: In this case, the program will be run as the user it is owned by (often root or another privilaged user filesystem wise, like the user bin). Since the program isn't designed to be run setuid root, it won't know to drop all these additional privilages and will just do everything as the user root. If the user can get the program to do something that it wasn't designed to do (via careful use of options or more creative tricks such as buffer overflows), this can lead to the user doing things you didn't want them doing...as root. Often, this is executing arbitrary code (basically doing whatever they want), which usually means bring up a shell as root. Once the user has this root shell, they basically own the system as it's like they logged in as root. A program that is designed to be run setuid root has a bug: Sometimes, programs designed to be run setuid root have a bug. XFree86, for example, would print the first line of whatever file you gave it for a config if an error occurred. Since the X server is setuid root, it can read any files (including the elusive /etc/shadow, the shadow password file containing crypted passwords). A bug was found where the user could simply specify /etc/shadow as a config file and XFree86 would flag it as an error and print the first line. Usually the first line was the entry for root. Oops, there goes your root password (crypted, but a modern PC can brute force the entire DES keyspace in a matter of hours or at worst a few days; MD5 may take a few weeks if the user is determined). Notice that this wasn't even a buffer overflow or a condition where arbitrary code could be executed! This was just creative [ab]use of a seemingly harmless bug. There are some things that absolutely have to be setuid root. Anything that needs to elevate privilages (su, sudo, etc), modify system config files (passwd, chfn, chsh, etc), or do stuff at a hardware level (X servers, etc) will have to be setuid root so that ordinary users can run them. There isn't anything one can do about this. It's just the way UNIX was made. There's nothing wrong with it; it just requires some careful coding (which should be standard anyway!). Back to the CD burner/ripping subject: just give the user read/write access to the CD device (generic and block). I like to make a group or two (cdburn, cdrom) that I can add people to (usually just me on my mostly single user desktop), make the device nodes owned by this group and set mode 664 or 660 (depending on my mood). This allows any user to access the device without needing setuid bits all over the place. The only thing the setuid bit was getting you was the filesystem permissions override CAP. X-CDRoase uses a different method. Rather than giving the user full access to the device (playing with filesytstem permissions is kinda an all or nothign thing), it uses a wrapper script (that's setuid to a certian
Re: [luau] Duplicating Music CD
Hi Wayne, As you suggested, I was trying to clarify to the list what I was trying to say. Programs should not be run SUID root unecessarily. I mentioned su and sudo as alternatives to SUID. MonMotha mentioned another solution which works when wonderfully when applications do not have differing expections of what those ownerships and permissions are. You made a suggestion that works well for an isolated single user workstation. I disgree about a policy of excessive use of SUID root in a default install; one that can run unintentionally installed on multi-user systems. Please do not take that as a personal attack. -Vince
Re: [luau] Duplicating Music CD
It turns out that either RH 8.0 failed to turn on the setuid for cdparanoia, or one of the rpms that I subsequently installed turned it off. A simple command chmod 4744 cdparanoia solved the problem. While I still couldn't duplicate audio CD directly, I am happy for now. From my experience, cdparanoia is a much better audio CD ripping program than cdda2wav. With the former, I consistly get a ripping rate of about 2.5~2.8x; whereas, the latter only gives me at best 1.4x (sometimes it even went below 1x). I would really appreciate it if other Linux users can also post their experience on various annoyances. If it gets crowed here, I'll be more than happy to find an alternate host. W. Wayne Liauh wrote: The problem I am having now appears to be that the xcdroast that came with RH 8.0 is broken. I installed the updated xcdroast rpms which seems to throw everything in further chaos--now everything is broken, including cdrecord.
Re: [luau] Duplicating Music CD
On Sun, Dec 08, 2002 at 07:10:29PM -1000, W. Wayne Liauh wrote: It turns out that either RH 8.0 failed to turn on the setuid for cdparanoia, or one of the rpms that I subsequently installed turned it off. A simple command chmod 4744 cdparanoia solved the problem. While I still couldn't duplicate audio CD directly, I am happy for now. I think it is a good thing that cdparanoia should not have the SUID bit set by default. It is one less possible overflow to worry about. A bit more hassle, but it is worth the security. I am not current on rpms, but the package manager can default to no, but prompt to see if you want it SUID. (Debian offers this.) -Vince
Re: [luau] Duplicating Music CD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 27 November 2002 06:13 pm, W. Wayne Liauh wrote: Reading an audio CD is much more complicated than we thought. (Think about it, even xcdroast is not able to do direct copying of audio CDs.) The problem I am having now appears to be that the xcdroast that came with RH 8.0 is broken. I installed the updated xcdroast rpms which seems to throw everything in further chaos--now everything is broken, including cdrecord. You need to use the cdrecord that is downloadable with the version of xcdroast you chose, i.e. for redhat 8.0, you need from this page: http://xcdroast.sourceforge.net/RPMS/a11/redhat-8.0/ cdrtools*1.11a40-1 xcdroast-0.98alpha00-1 works for me here. It cannot do cd to cd, though. It must be downloaded to an image directory defined in setup and then written to the CDR. Aside:It makes it difficult to master mixed cd's as each image directory has files named track_01 and it takes time to cross reference. dean -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE95+a3ppeRAf8wEb8RAs9KAJ0UR0V3IsBzrSYrx/uwFyzgdn4wYwCfbmNu 2hqbPIvxsoAS1dEzL8ptCTU= =jqYt -END PGP SIGNATURE-
Re: [luau] Duplicating Music CD
whenever wrote: Have you tried cdrdao ? using the copy command/option. Unfortunately that won't work for me. It requires a different source and destination drive. My CD-ROM drive can't rip CDs worth a darn (about 2x and it has so many errors...), so I have to rip with my burner. Of course I can't burn while ripping with the same drive. I need an app that can read it to an image, then burn it back. --MonMotha pgpuSv9uLQhmH.pgp Description: PGP signature
Re: [luau] Duplicating Music CD
hmmm.. I only have one drive and works fine for me, have you even try: cdrdao copy --device device name ? @pioneer data]$ cdrdao copy --device /dev/scd0 Cdrdao version 1.1.5 - (C) Andreas Mueller [EMAIL PROTECTED] SCSI interface library - (C) Joerg Schilling L-EC encoding library - (C) Heiko Eissfeldt Paranoia DAE library - (C) Monty Check http://cdrdao.sourceforge.net/drives.html#dt for current driver tables. Using libscg version 'schily-0.5' /dev/scd0: YAMAHA CRW2100S Rev: 1.0N WARNING: Cannot read driver table from file /usr/local/share/cdrdao/drivers - using built-in table. Using driver: Generic SCSI-3/MMC - Version 1.2 (options 0x0010) Starting CD copy at speed 16... Track ModeFlags StartLength 1 AUDIO 0 00:00:33(33) 03:21:32( 15107) 2 AUDIO 0 03:21:65( 15140) 04:26:55( 20005) 3 AUDIO 0 07:48:45( 35145) 04:08:63( 18663) 4 AUDIO 0 11:57:33( 53808) 04:33:42( 20517) 5 AUDIO 0 16:31:00( 74325) 04:33:63( 20538) 6 AUDIO 0 21:04:63( 94863) 04:13:50( 19025) 7 AUDIO 0 25:18:38(113888) 03:42:72( 16722) 8 AUDIO 0 29:01:35(130610) 03:08:50( 14150) 9 AUDIO 0 32:10:10(144760) 04:18:45( 19395) 10 AUDIO 0 36:28:55(164155) 03:58:50( 17900) 11 AUDIO 0 40:27:30(182055) 03:42:53( 16703) Leadout AUDIO 0 44:10:08(198758) Copying audio tracks 1-11: start 00:00:00, length 44:10:08 to cddata26100.bin. .. Track 1... Track 2... Found pre-gap: 00:03:00 On Thursday 28 November 2002 10:15 am, you wrote: whenever wrote: Have you tried cdrdao ? using the copy command/option. Unfortunately that won't work for me. It requires a different source and destination drive. My CD-ROM drive can't rip CDs worth a darn (about 2x and it has so many errors...), so I have to rip with my burner. Of course I can't burn while ripping with the same drive. I need an app that can read it to an image, then burn it back. --MonMotha
Re: [luau] Duplicating Music CD
For a background info, I used the following script to do a direct (sorta) CD copying from /dev/cdrom (read-only CDROM) to /dev/scd0 (CD-RW): #/bin/bash mkdir /var/cd cd /var/cd cdda2wav -D /dev/cdrom -B -owav cdrecord -v dev=0,0,0 -audio *.wav rm -r /var/cd For some reason, this script no longer works in RH 8.0. OTOH, this is a very simplistic script and was very slow even when it worked. (xcdroast doesn't do direct CD copying, thus the above script was written.) W. Wayne Liauh wrote: Does anyone know how to duplicate music CDs in either Red Hat or Mandrake/
Re: [luau] Duplicating Music CD
W. Wayne Liauh wrote: Does anyone know how to duplicate music CDs in either Red Hat or Mandrake/ ___ LUAU mailing list [EMAIL PROTECTED] http://videl.ics.hawaii.edu/mailman/listinfo/luau ## Hi Wayne, I have had no success in installing CDRW on Linux. I installed a Sony IDE CDrom on A FreeBSD box and it worked the first try for Audio and Data. You might want to consider building up a FreeBSD box if you want a solid CDRW for doing a lot of copies. Aloha! Al Plant - Webmaster http://hawaiidakine.com Providing FAST DSL Service for $28.00 /mo. Member Small Business Hawaii. Running FreeBSD 4.5 UNIX Caldera Linux 2.4 RedHat 7.2 Support OPEN SOURCE in Business Computing. Phone 808-622-0043
Re: [luau] Duplicating Music CD
W. Wayne Liauh wrote: For a background info, I used the following script to do a direct (sorta) CD copying from /dev/cdrom (read-only CDROM) to /dev/scd0 (CD-RW): #/bin/bash mkdir /var/cd cd /var/cd cdda2wav -D /dev/cdrom -B -owav cdrecord -v dev=0,0,0 -audio *.wav rm -r /var/cd For some reason, this script no longer works in RH 8.0. OTOH, this is a very simplistic script and was very slow even when it worked. (xcdroast doesn't do direct CD copying, thus the above script was written.) W. Wayne Liauh wrote: Does anyone know how to duplicate music CDs in either Red Hat or Mandrake/ ___ LUAU mailing list [EMAIL PROTECTED] http://videl.ics.hawaii.edu/mailman/listinfo/luau ### cdrecord is what we use with FreeBSD for copying the files from the harddrive and it should run from the command line with no difficulties. You may want to examine the command line code for FreeBSD and see if that helps you to see any problems. We copy the CD to be copied onto the hd in a seperate directory for doing this then copy that to the CD rom using cdrecord. I haven't seen any way to go direct from a cd to a cdrom. I think you are making a temp directory with your script to transfer the data or audio right? Aloha! Al Plant - Webmaster http://hawaiidakine.com Providing FAST DSL Service for $28.00 /mo. Member Small Business Hawaii. Running FreeBSD 4.7 UNIX Caldera Linux 2.4 RedHat 7.2 Support OPEN SOURCE in Business Computing. Phone 808-622-0043
Re: [luau] Duplicating Music CD
W. Wayne Liauh wrote: Does anyone know how to duplicate music CDs in either Red Hat or Mandrake/ I think you should just be able to go cp /dev/cdrom musiccd.iso and then use your favorite cd recording program to burn the iso to the the cd. --Ray
Re: [luau] Duplicating Music CD
Ray Strode wrote: W. Wayne Liauh wrote: Does anyone know how to duplicate music CDs in either Red Hat or Mandrake/ I think you should just be able to go cp /dev/cdrom musiccd.iso and then use your favorite cd recording program to burn the iso to the the cd. --Ray Music CDs are recorded in a different format, that I don't even know if they can be access via the block device. Also, since the music is in multiple tracks, this wouldn't work. You can use a program like cdda2wav or cdparanoia to rip the tracks, then reburn them back, but then you lose all the metadata. I know xcdroast will do it, but a nice command line tool would be great for me too. --MonMotha pgphOglhiHX2l.pgp Description: PGP signature
Re: [luau] Duplicating Music CD
Music CDs are recorded in a different format, that I don't even know if they can be access via the block device. Also, since the music is in multiple tracks, this wouldn't work. D'oh. You're right of course. I suppose my idea would probably blend all the tracks together into one long track. I assume the audio is available from the block device for most newer drives tho, because most newer drives support cdda extraction (w/o the digital - analog - digital evilness), and I assume tho do that through the ATAPI interface. I don't know, maybe the cdrom driver uses an ioctl interface to manipulate the drive and access various audio tracks and things.. --Ray
Re: [luau] Duplicating Music CD
Reading an audio CD is much more complicated than we thought. (Think about it, even xcdroast is not able to do direct copying of audio CDs.) The problem I am having now appears to be that the xcdroast that came with RH 8.0 is broken. I installed the updated xcdroast rpms which seems to throw everything in further chaos--now everything is broken, including cdrecord. I don't think you can access an audio CD without going through cdda2wav or cdparanoia or other equivalent programs. Insert an audio CD, run any CD player program, then do a kdf, and you will find out that the CDROM is not even mounted. Ray Strode wrote: Music CDs are recorded in a different format, that I don't even know if they can be access via the block device. Also, since the music is in multiple tracks, this wouldn't work. D'oh. You're right of course. I suppose my idea would probably blend all the tracks together into one long track. I assume the audio is available from the block device for most newer drives tho, because most newer drives support cdda extraction (w/o the digital - analog - digital evilness), and I assume tho do that through the ATAPI interface. I don't know, maybe the cdrom driver uses an ioctl interface to manipulate the drive and access various audio tracks and things.. --Ray ___ LUAU mailing list [EMAIL PROTECTED] http://videl.ics.hawaii.edu/mailman/listinfo/luau
Re: [luau] Duplicating Music CD
Hi Al- I have FreeBSD 5.0 rc2 downloaded, and will play with it during the holiday. BTW, I would appreciate it if you could explain what kind of services your ADSL subscription provides. For example, if I am thinking about putting together a vnc for Linux demo, how would you facilitate my need? (But 99+% of my ideas were aborted.) Thks.
Re: [luau] Duplicating Music CD
I don't think you can access an audio CD without going through cdda2wav or cdparanoia or other equivalent programs. Insert an audio CD, run any CD player program, then do a kdf, and you will find out that the CDROM is not even mounted. I've been wanting to get into kernel programming for a while now. I think that writing a cdda file system would be a neat little project. Since, I've not really done any kernel programming (other than helping jimen) it might take me a while, but i'm putting it in the back of my mind for when i have a few days free time. Thanksgiving break would actually be perfect if I didn't have a bunch of school work to get done. --Ray
Re: [luau] Duplicating Music CD
W. Wayne Liauh wrote: Reading an audio CD is much more complicated than we thought. (Think about it, even xcdroast is not able to do direct copying of audio CDs.) The problem I am having now appears to be that the xcdroast that came with RH 8.0 is broken. I installed the updated xcdroast rpms which seems to throw everything in further chaos--now everything is broken, including cdrecord. I don't think you can access an audio CD without going through cdda2wav or cdparanoia or other equivalent programs. Insert an audio CD, run any CD player program, then do a kdf, and you will find out that the CDROM is not even mounted. This is correct. There is no filesystem on audio CDs to mount nor is the data stored in the same way as the CD-ROM standard. CD Audio takes advantage of the fact that the data type is known to pack more data into the same space and still have acceptable ECC (which is how many copy protection algorithms work, by munging the ECC so intelligent devices will choke on it). cdparanoia or cdda2wav use the reader's rip function to have it read the CD audio digitally (sometimes at very high speeds, sometimes at 1x, sometimes somewhere in between) and get a PCM data stream back. This is different from the normal play CD functionality which has the drive itself do a D/A conversion and put an analog signal out the little CD audio cable (not the SPDIF one, but the 4 pin analog one). --MonMotha pgprxAFUMB5Lt.pgp Description: PGP signature
