On 1019822142 seconds since the Beginning of the UNIX epoch
xs@kittenz.org wrote:
>
>on Thu, Apr 25, 2002 at 05:46:31PM -0700, Jeremy C. Reed wrote:
>> Sudo is useful.
>> 
>> For example, sudoers configured for some users (on a home system) to run
>> one command: /path/to/xcdroast.

>Would this work?
>
>group add toasters
>chmod 660 /dev/rcd0d
>chgrp toasters /dev/rcd0d
>sysctl -w vfs.generic.usermount=1
>user mod -G toasters user1

Actually, it depends on the use case of the system.  I've found that
quite a number of these depend not on `who you trust to play audio/use
a cd drive' but rather `who is sitting at the console'.  It makes sense
for many cases that the person who is allowed to access the device is
the one who can reach out and touch the device.  And in those cases just
chown the device in /usr/X11R6/lib/X11/xdm/GiveConsole and chown it back
in /usr/X11R6/lib/X11/xdm/TakeConsole.  For quite a long time I did this
with /dev/audio, /dev/sound, /dev/fd0?, and others.  I think that it is
more conceptually tied to what is typically desired.

If we had a capability model, then xdm or login could just assign the
capabilities to the user as they logged in.  But, that's a very different
security architecture and has some different setbacks Such as if I ssh
in to a box on which I am logged in on the console, I can't play audio
unless I initiated screen(1) from the console and I steal the session---not
to mention that I can start screen(1) and then log out, leaving me floppy
access which I can modify when the next user logs in before they mount
it.  So that'd have to be worked out.  (Please note that I am not
advocating a capability model.)

 == Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/  ==
 == The Unofficial NetBSD Web Pages        http://www.Imrryr.ORG/NetBSD/  ==
 == The NetBSD Project                            http://www.NetBSD.ORG/  ==