From: jg@pa.dec.com (Jim Gettys)
To: linux-hotplug@vger.kernel.org
Subject: Re: [Xpert]Re: User-level Tasks in Hotplug Scripts?
Date: Tue, 05 Feb 2002 15:19:37 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-101292242020576@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-101272582331992@msgid-missing>
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
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2002-02-05 15:19 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-03 8:43 [Xpert]Re: User-level Tasks in Hotplug Scripts? Dr Andrew C Aitchison
2002-02-03 17:43 ` Owen Taylor
2002-02-03 19:06 ` Jim Gettys
2002-02-03 19:59 ` Christer Palm
2002-02-03 20:46 ` David Brownell
2002-02-03 21:13 ` David Brownell
2002-02-03 23:49 ` Christer Palm
2002-02-04 5:57 ` Owen Taylor
2002-02-04 15:15 ` Vladimir Dergachev
2002-02-04 23:17 ` Oliver Neukum
2002-02-05 1:22 ` Christer Palm
2002-02-05 1:54 ` David Brownell
2002-02-05 2:14 ` Christer Palm
2002-02-05 2:41 ` David Brownell
2002-02-05 4:49 ` Vladimir Dergachev
2002-02-05 7:53 ` Oliver Neukum
2002-02-05 8:47 ` Dr Andrew C Aitchison
2002-02-05 8:56 ` Oliver Neukum
2002-02-05 11:21 ` Christer Palm
2002-02-05 11:35 ` Oliver.Neukum
2002-02-05 15:19 ` Jim Gettys [this message]
2002-02-05 18:37 ` Jim Carter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-linux-hotplug-101292242020576@msgid-missing \
--to=jg@pa.dec.com \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).