Alexander Skwar <[EMAIL PROTECTED]> writes:
> > to enable some users and not some others to use it by specifying who
> > is in this group.
> > and to let these users having access to the required devices (/dev/sg*,
> > /dev/scd*, /dev/pg*, and /dev/pcd* [the /dev/p* devices are for parallel
> > writers])..
>
> But why should not anyone be able to create an iso image? mkisofs doesn't
> do anything remotely harmful (besides writing an awful lot of data - but if
> the user has the space, why not?).
this was needed in the old days in order to read old sessions in
multi-sessions mode. it seems not anymore mandatory.
If someone want to test multi-mode ...
> mkisofs doesn't need any of the devices you've just listed. Your comment
> holds certainly true for cdrecord, and to some extent also for cdda2wav -
> but in no way for mkisofs.
Yes it needs it. See above for multi-session mode
> > As for cdrecord, it MUST be SUID root because it locks itself in
>
> I don't care about cdrecord - because you are exactly right about what you
> write.
>
> > root suid (or guid) binaries are very, very _bad_.
> > better giving accesse to a sub-system than to the whole system in case
> > of security hole.
>
> Yes, of course - but if a user has enough free space, he could also fill it
> with dd if=/dev/zero of=BANG - how is that ANY different than
> mkisofs?
i was not speaking of filling the hd. I spoke of security hole such
as buffer overflow. Imagine such an overflow on cd title wich let you
run a root shell ?? Better a cdburner shell than a root shell!
