Re: documentation on permissions for cdrom device -- where?

[Jamie Fifield <fifield@cs.dal.ca>]

On 1 Jan 1999, Kalle Olavi Niemitalo wrote:

> Wichert Akkerman <wakkerma@cs.leidenuniv.nl> writes:
> 
> > Previously Kalle Olavi Niemitalo wrote:
> > > This solution isn't very good either, since the user can create a
> > > setgid program when she's at the console and run it later.  Or she can
> > > leave a shell running in screen(1).  Or just leave a process holding
> > > the device open.
> > 
> > The obvious solution to that is the revoke() system call, which should
> > be used by anything that does things like spawning a login-shell and
> > giving away groups. It should be in the 2.1 kernels.
> 
> Okay, so that prevents her from just keeping the device open.  But how
> about the two other ways, which rely on preserving the group id and
> using it to open the device later?
> 
> You could mount all user-writable directories -o nosuid and kill all
> user processes after she logs out, but that would seem rather fascist
> to me.
> 
> Or did you mean to junk the groups and instead chown the
> audio/scanner/whatever to the console user, like the tty devices are
> chowned to their respective users?

<delurk>
Chown'ing (a la Solaris) is somewhat broken anyway.  All chown does to
discourage the various noises (as described before) is force the prankster
to log into the console beforehand.  The would be prankster can, say, log
into every workstation in the lab, begin a program in the background that
opens the audio device (exporting the display elsewhere if need be) and
then log off again.  This can allow for a lot of fun, as the prankster can
now time and coordinate the fun. :)

I think to properly implement the chown scheme, when the console user logs
out, it will need to check for open references to the audio device in
every process and do something about them instead of just a chown back to
root again.

Then again, I could be way off and the chown back to root upon
logout blocks non-console users from using the device.  I'm not near a
Solaris system to check, but I'm pretty sure I've done this before.  I
mean, once you've got a valid file descriptor, the kernel's got a
corresponding one too in it's file tables.  Surely it doesn't check to
make sure it's still legal on each access?
<lurk>

--

Jamie Fifield <fifield@cs.dal.ca>

Black holes are where God divided by zero.