Re: X and other visions

[Bas Wijnen]

Hi,

A comments which I consider more important, which is also the reason I
crosspost this to l4-hurd:

Suppose we have a system in a classroom, as described below.  At (local)
login, a capability for the sound card should be given out.  At logout, this
capability should be revoked, including all copies made of it.  This to
prevent the user from setting up a server in the background enabling him or
her to use the sound card remotely.

Does the capability library have a system for that?  If not, can it easily be
implemented in the server using the lib?  I think it should be in the library,
because revoking a capability should always include all copies, AFAICS.

On Sun, Jun 13, 2004 at 03:45:15PM +0200, Alfred M. Szmidt wrote:
>    Things like these are typical tasks for a console user:
>    - turn off the computer (on desktop machines)
> 
> Also a typical task for a remote user; atleast w.r.t. to rebooting
> which is essentially the same with some minor details.

Suppose my system is in my bedroom, and I want to switch it off before going
to sleep.  Then the system should be rebootable by
0) the system administrator
1) the locally logged in user
Because I don't want to become administrator every time I want to go to bed.
And I don't want any other user to be able to reboot it remotely either.

Note that this is very well possible with a capability system, as Marcus
wrote (is writing?) for the Hurd on L4.  The "shutdown" capability is simply
given to a process at login by the "login" program, but not by "sshd".  Root
should simply be allowed to do a shutdown even without the capability (or
perhaps it should get one if it requests it, unlike any other process).  The
nice thing about this is that for example the window system can throw its
capability away before starting a program which should not be able to shutdown
the computer.

>    - access the sound card and the mixer
> 
> Ditto.  I infact use the mixer and play songs remotely each and
> everyday.

Also here capabilities are great :-)  You should of course be able to set up
the system in a way that you can control who is allowed to receive a new
capability and who isn't.  For shutdown, it usually means "root gets it,
others don't".  For sound you may want to set it to "everyone gets it", but
many others might want "root and my_user get it, others don't", or something.
Or it is given to you at console login, but not at remote login.  The
possiblities are endless :-)

>    - start X sessions on the local machine
> 
> X doesn't really differentiate between local and remove machines from
> what I know.  So a remote X session is essentially the same as a local
> one.

Starting X does not make sense from a remote machine.  X uses the hardware of
the computer it runs on, so if you start it remote, it still takes over the
local display.  X *clients* don't really care if they're running remote
(except that SDL programs are dead slow if not run locally ;-) ), but that's
not what he was talking about.

>    The current console user(s) should have almost root rights
>    (regarding hardware access, so not installing software),
> 
> Why give the user root access at all? Just make a new group and user,
> call them mixer for the mixer example.  And then make the owner of
> /dev/mixer mixer, and the group mixer.  Then just plunk in all users
> that want to change the volume into the group mixer.

The point is that the separation is not on a user basis.  Whoever happens to
login at the console should be allowed to use the sound card, the floppy
drive, the tape streamer, the graphics card, etc.  All others should not.
Consider for example a computer lab in a school.  While it'd be fun to see one
user use all sound cards in the room at once, it most certainly is something
the system administrator wants to prevent.  Again, capabilities let you do
this :-)

> Or just allow everyone to read/write to /dev/mixer, which is obviously
> the right thing todo.

Perhaps in your "media center" setup, but not everywhere, see above.

>    on the other hand the network users should have less rights (it
>    usually doesn't make sense when a remote user is permitted to turn
>    the volume up and to play an annoying sound ...).
> 
> Why not? I think it makes perfect sense.  Say I have a "audio system",
> that plays songs.  I connect to it remotely; shouldn't I be able to
> change the volume there?  Should I be _forced_ to go to the console to
> change the volume?

No, you (as a sysadmin) should be able to set it up according to your wishes.

> Saying what a user should be allowed to or not based on from where he
> or she is login in from is anti-social.

It's up to the sysadmin to decide who should be able to do what.  The sysadmin
shouldn't be forced to make it an anarchistacal computer (but (s)he should be
able to.)

>    2. the file permission management has to be improved (it has to be
>    improved anyway).
> 
> Why?  And what is wrong with just providing ACL support?

For device files, often it's not "user X" who should be allowed to use it, but
"the user who is doing Y".  ACLs cannot handle such things I think.
Capabilities, again, can :-)

> Why?  And how do you decide what needs "console intervention" and what
> doesn't?  Isn't the point of GNU/Hurd to allow users to do whatever
> they might wish to do without screwing up for others?

As with all operating systems, everything should be possible.  It's up to the
system administrator to choose what (s)he wnats.  Capabilities allow the
administrator to give the users much more freedoms without compomising the
whole system's security.  But it's still up to the administrator if those
rights are indeed given to the users.

Bye,
Bas Wijnen

-- 
I encourage sending me encrypted e-mail.
Please send the central message of e-mails as plain text in the message body,
   not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
for more information, see http://129.125.47.90/e-mail.html

pgprScj1WT3dV.pgp
Description: PGP signature