Re: CD burning without root priviligdes
On Wednesday 13 November 2002 12:28, Frank Van Damme wrote:
> On Wednesday 13 November 2002 03:48, Carlos Carvalho wrote:
> > I'm glad to finally see a discussion of this subject. I find the
> > structure of CD recording software in Linux quite outdated and
> > inadequate for a multi-user environment (note that this isn't a KDE
> > problem). The software was clearly conceived to be used by someone
> > with root access sitting on the console of the machine, which is
> > almost the opposite of what is necessary for a CD-recorder server.
>
> It's ugly allright... but why does writing cd's need root privilegies? Isn't
> it an inadequacy in the kernel?
>
> > I'd like to have something similar to what we have for scanners: a
> > daemon (that may run as root if necessary) waiting for connections
> > through the net and operating the device, or interfacing with a
> > driver. The user interacts remotely with a client software (of course
> > the user may via localhost as well). This approach has many
> > advantages:
>
> Oh no... not another daemon...
If you hate daemons: How about a program started via hotplug(?) when
a cd is inserted? >;-)
> > a) it removes permissions problems from the scene;
> > b) no need for authentication of users, because it's not the user that
> > has access, it's the daemon. Access to the daemon is controlled by
> > standard methods (firewall, tcp wrappers, etc.);
>
> Er, maybe. You mean because the daemon runs as root? Then it just places the
> permission problem somewhere else: with the daemon. There should always be a
> way to go without daemons in any case (if you're just using the writer
> locally).
Right but a daemon is much more flexible how do deal with authorization and access
rights. Having to logout/in from/to X session to activate new group group member ship
is something like rebooting Windoof after every software installation. Stupid but necessary
(and no: su/ssh etc is no good solution of Mum and Dad). I'm really curious
what solution the debian desktop project will develop.
> > c) it allows the use of the recorder by users in other machines. This
> > way we can have a diskless machine with just a recorder and users
> > connect from a login server via the client software. I have here a
> > scanner connected to such a machine that also controls the printers
> > and works as a X-term, while the login server remains locked in
> > another room and users reach it from X-terminals.
yes, yes please ;)
>
> Let me guess: ltsp addon? :-)
>
> The only thing I can think of that currently comes close is webcdrwriter. It's
> a java applet client-side and a daemon that operates cdrecord server-side.
>
> > I use this approach for CD readers, floppy drives, scanners,
> > printers, zip drives, but I cannot do it for CD recorders :-( :-(
>
> Floppy drives? without mounting them on the server you mean? how?
with floppy:/a and mtools one can work with floppies without mounting them.
And for remote access:
ds10[1] ~ # apt-cache search floppyd
floppyd - Daemon for remote access to floppy drives
>
> (I burned a few floppy controllers a while ago)
>
> > I understand that cdrecord and family were written at a time when
> > recording a CD was a delicate operation. However with the fast
> > machines and network of today the picture has changed completely, and
> > it seems to me that a revamp is really necessary. In the process we
> > could perhaps get rid of scsi emulation...
>
> Uh-oh... and now comes the argumentation "today, we all have pretty big
> machines so we can afford to make an overhead-producing daemon :-/
> I like cdrecord for its power, flexibility, performance, stability and low
> system requirements. Maybe it's better to remove the need for root
> privilegies completely (what is a multiuser system worth if you have to do
> anything that's useful with root privilegies?) Maybe cdrecord doesn't need to
> get trashed, it may be just enough to make it run as a client of that fancy
> daemon you're intending to code :-) in a way like now gui clients use
> cdrecord.
>
> /----------------\ /----------\ /--------\
> So: | $kde*cd*burner |=--->| cdrecord |=-->| kernel |
> \----------------/ \----------/ \--------/
>
> ||
> \/
> /----------------\ /------------\ /----------\ /--------\
> | $kde_cd_burner |=--->| netCDaemon |=--->| cdrecord |=--->| kernel |
> \----------------/ \------------/ \----------/ \--------/
>
>
> btw, I think freebsd already writes cds without scsi emulation isn't it?
linux > 2.5.44 can do it. http://linux.bkbits.net:8080/linux-2.5/ChangeSet@..1.786.1.22?nav=index.html|tags
torvalds
1.781.29.3
Remove ide-cd reliance on "struct packet_struct", make it use
the native "struct request" fields instead.
Simplify and clean up sense data handling.
This makes IDE CD-RW burning possible without ide-scsi.c
> > The same strategy is used in the Network Audio System (NAS) developed
> > by NCD and available in the libaudio-dev package. Next is the camera :-)
>
> Artsd has network transpareency doesn't it?
Yes, but I could not come up with good solution to run artsd on an X-terminal.
artsd -> nas daemon is also possible but when I tried ( ~ 1 year ago) the output
was horrible. Same sample played several time with a time offset. that was
on a 100mb switched network). Does NAS work for someone? Worth to try
again?
>
> > Any volunteers? :-)
>
> Within a few months maybe ;-)
please s/maybe// :)
Achim
>
> Frank
>
>
> --
> To UNSUBSCRIBE, email to debian-kde-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
>
--
To me vi is Zen. To use vi is to practice zen. Every command is
a koan. Profound to the user, unintelligible to the uninitiated.
You discover truth everytime you use it.
-- reddy@lion.austin.ibm.com
Reply to: