From mboxrd@z Thu Jan 1 00:00:00 1970 From: jg@pa.dec.com (Jim Gettys) Date: Tue, 05 Feb 2002 15:19:37 +0000 Subject: Re: [Xpert]Re: User-level Tasks in Hotplug Scripts? Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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: > Date: Tue, 5 Feb 2002 12:35:41 +0100 (MET) > To: Christer Palm > Cc: , > Vladimir Dergachev , > Jim Gettys , David Brownell , > Ryan Shaw , > , , > > 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