[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: CD burning without root priviligdes



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

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

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

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? 

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

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

> Any volunteers? :-)

Within a few months maybe ;-)

Frank



Reply to: