Re: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[jg pa dec com (Jim Gettys)]

Please also understand that commercial Linux is succeeding in server 
systems.  Designing just for single user desktops is very short-sighted; 
commercially, much as I personally wish fervently otherwise, X desktops 
are not currently important.  But managing a server farm gracefully is 
commercially important.  And as I look into my tea leaves of the future, 
it looks to me we are moving toward a world (even at home), of random 
dedicated server boxes with remote displays.  And we are beginning to 
see deployment of Linux desktops in enterprises; again, remote configuration 
needs to be possible.

And people want to administer beowulf systems as though they were
one system, not N.

Again, the issue here for X to deal with is delegation of authorization
to connect to the user's X server.  Once we have that, various schemes
all work, and it will take a while to sort out the right policies on
the hotplug side of things, from what I can see of the discussion.

And yes, I want as little of this as possible: as much as possible, things
should plug in a work without human intervention.  But human intervention
needs to be possible.

More comments below.
                        - Jim
> Sender: linux-hotplug-devel-admin lists sourceforge net
> From: <Oliver Neukum lrz uni-muenchen de>
> Date: Tue, 5 Feb 2002 12:35:41 +0100 (MET)
> To: Christer Palm <palm nogui se>
> Cc: <Oliver Neukum lrz uni-muenchen de>,
>         Vladimir Dergachev <volodya mindspring com>,
>         Jim Gettys <jg pa dec com>, David Brownell <david-b pacbell net>,
>         Ryan Shaw <ryan shaw stanfordalumni org>,
>         <linux-hotplug-devel lists sourceforge net>, <wm-spec-list gnome org>,
>         <xpert XFree86 Org>
> Subject: Re: [Xpert]Re: User-level Tasks in Hotplug Scripts?
> -----
> On Tue, 5 Feb 2002, Christer Palm wrote:
> 
> > Oliver Neukum wrote:
> >
> > >>And what would the problem be with using an event distribution mechanism
> > >>that would require the listener to have certain privileges?
> > >>
> > >
> > > You may not want to base the distribution on privileges but on identity.
> eg
> > > you want to associate some ports with some keyboards.
> > > But in principle such a scheme should work.
> > >
> >
> >
> > Not only in principle, but also in practice, as I stated earlier. I
> > would suggest having a look at "man pam_console", which is the way this
> > kind of stuff is currently implemented.
> >
> > There is no concept of more than one "local", i.e. console, user in
> > Linux (or any other OS that I know of, for that matter), and changing
> > that would be quite some work. Except for obscure vintage machines, does
> > computers with more than one direct-attached keyboard even exist??

Various people keep saying they want such things.  I'm personally somewhat
skeptical at this date, but making it hard/impossible seems wrong to me.

But on server systems, there are often many local users; they've logged
in, and are using the system.  Some may have full priviledges to the system.
Any of them, potentially, might be the operator of the system.

PAM looks interesting; it came along since the last time I groveled in 
the area...  Particularly if combined with Kerberos, it may provide a 
solution that meets the network transparency requirements (while not 
requiring kerberos in the simple single machine case).  But I'll have to 
do some homework.

> 
> Support for more than one local user is a cornerstone of X and supported
> in the kernel as well. In fact the X people are reportedly proud that
> they've made it work.

Yup.  Since 1984.  Not rocket science.  And many people use systems
without monitors on them.  People log into remote systems routinely, and
expect it to work, and they should be able to be notified even if
not on the local console.

> Linux does support several graphics adapters, X supports the
> machine:console.monitor notation and you can hook up dozens of
> USB keyboards let alone terminals.
> 
> One local user is the typical case, but others must in principle work.

Exactly.

> 
> > Anyway, in Linux, PAM is usually what (automatically) provides the
> > mapping between session and privileges. You could add your own PAM
> > module to associate the necessary privileges with a user session based
> > on whatever parameters you want.
> 
> You need filtering events as well. I don't want anybody to know
> that I've plugged a webcam into the hub in my bedroom.

Yup.  Certainly we do need filtration of some sort, somewhere.

                     - Jim

--
Jim Gettys
Cambridge Research Laboratory
Compaq Computer Corporation
jg pa dec com