User-level Tasks in Hotplug Scripts?
Quoted 8 lines · Jim Gettys
OK, folks (both X and wm-spec-list folks, that is, that I've added to this thread):
How do we want to solve this problem?
We need a secure, interoperable way for configuration scripts running as root to pop up configuration GUI's on user's servers, and we need it soon (yesterday), as hot-plug is now a reality on Linux systems....
Are you sure you want to do this ?
Are you *absolutely* sure you want to enable this in the default installation ?
If the root script cannot open a popup on the display, maybe it is because the display is currently being used by someone who shouldn't have access to the popup.
If I have a stand-alone machine, sure I want a popup when I install a new printer/camera/player/reader in the USB/Firewire/PCMCIA socket. However, if this is a classroom machine I might not wish to allow any user to just plug in their device and use it. If the root script pops up a config on their window they have just acquired more priviledges than I wish to give them.
How easy is it for the admin to configure what the user can do (here editing a single text file isn't necessarily harder than using a GUI) ? Perhaps I want to allow the user to plug in his CompactFlash card reader to download files from his camera, but I don't want the machine to run suid root programs that he copied onto the card at home. (Sorry I don't know how much this has been solved by the 2.4 device file system, maybe this isn't a problem).
---
I assume that you will syslog what popups the scripts attempt to start, so that we still have a log trail when things go wrong.
Now for some ideas about getting the popup onto the display.
RedHat 6.2 ships with pam modules for propagating Display and Xauthority cookie through su. If the script is started from the desired display that might be enough to allow the popup to appear.
If the popup is started by some long running process, you might wish to keep a User/Display pair for the destination of the popup and su (ssh for the remote case?) to that user before starting the popup. Note that in this case both ssh X forwarding and the pam su module mentioned may will attempt progagate Display and cookie in the wrong direction.
Quoted 4 lines
Handling this for the local case is first priority, but we should give some thought about the possibility that the administrator's display is somewhere else in the network (e.g. we're configuring a server system's hotplug event, so the admin is elsewhere).
You may want the popup to appear in more than one place.
if the hot-plug is authorized, the admin is likely to be at the server when it occurs; if he is expected to configure anything from the popup it needs to appear on the local display. If the hot-plug is unauthorized a popup on the admin's desk might be very much appreciated.
Quoted 2 lines
Things to keep in the back of our minds is that we already have Kerberos 5 in the X server and library, so don't dismiss the remote case out of hand.
I'm a fan of tunnelling X over ssh; can you do it backwards ? I'd better note however that I've seen versions/installations which use the default .Xauthority and those which set up a new .Xauthority for each tunnel, I'd guess that that could complicate matters.
For the remote case you can't assume that the display is running the same OS/distribution as the client, and every multi-machine site is different. While it makes sense to try to package something which works out of the box for the simple case, here the admin needs to have clear documentation and easy access to the whole config. GUIs that do everything 90% of the time wont cut it, we need access to the whole system, ideally not more than two files per machines (one for command options, one
for access lists) that admins are encouraged to customize for their site. A GUI that makes things simple but hides what is really going on is out of order here.
Quoted 52 lines
- Jim
Quoted 38 lines
Sender: [email protected]
From: David Brownell <[email protected]>
Date: Fri, 01 Feb 2002 15:58:31 -0800
To: Ryan Shaw <[email protected]>,
[email protected]
Subject: Re: User-level Tasks in Hotplug Scripts?
-----Quoted 2 lines
First question: Is the hotplug script the
right place for this? If not, where is?Sure. Setup scripts are often used to do such stuff.
Quoted 5 lines
Second question: If the hotplug script is
the right place, why doesn't the following
work?su - ryan -c "nautilus --display=:0.0 >
/home/ryan/nautilus.log2>&1" &My guess would be it's an X11 permissions problem, or maybe a PATH= problem (is nautilus in the path?) but what'd be most interesting would be the diagnostics from that "su" command. That'll say why it fails.
The general issue with firing up GUI applications on hotplug events is that there's no standard way that a program running as one user (say, root) can locate the X server used by another (like "ryan", even assuming he is logged on only once :), and then get permission to talk to that server.
As a rule, GUI IPC architectures use some intermediary process that runs some kind of combined naming/activation service (maybe based on CORBA) to talk to applications, rather than allowing users to talk directly to those X servers. After all, if you can talk directly, you can take over the whole desktop, snooping for passwords or whatever.
Quoted 7 lines
- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel_______________________________________________
Xpert mailing list
[email protected]
http://XFree86.Org/mailman/listinfo/xpert
Signature · 8 lines
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [email protected] http://www.dpmms.cam.ac.uk/~werdna _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 14 lines · Dr Andrew C Aitchison
Quoted 8 lines · Jim Gettys
OK, folks (both X and wm-spec-list folks, that is, that I've added to this thread):
How do we want to solve this problem?
We need a secure, interoperable way for configuration scripts running as root to pop up configuration GUI's on user's servers, and we need it soon (yesterday), as hot-plug is now a reality on Linux systems....
Are you sure you want to do this ?
Are you *absolutely* sure you want to enable this in the default installation ?
Quoted 9 lines
If the root script cannot open a popup on the display, maybe it is because the display is currently being used by someone who shouldn't have access to the popup.
If I have a stand-alone machine, sure I want a popup when I install a new printer/camera/player/reader in the USB/Firewire/PCMCIA socket. However, if this is a classroom machine I might not wish to allow any user to just plug in their device and use it. If the root script pops up a config on their window they have just acquired more priviledges than I wish to give them.
There's no reason at all that the configuration GUI has to automatically have root privileges; I would tend to expect something along the lines of:
A new device "USB Magic Camera" has been detected. Please enter the root password to configure this device:
..............
[ Cancel ] [ OK ]
Regards,
Owen
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Owen:
This is certainly true: but not sufficient...
Here's the sequence as I understand it:
1) new device gets plugged in.
2) system has to figure out what driver to use.
3) if it has seen it before, presumably it can consult some sort of database to help hook it up, both by whatever driver parameters it needs, and to hook it up to a user level program it activates. We're done at this point.
4) if the system has never seen it before, we have to somehow ask the user what to do.
5) the driver finally gets loaded, with the user specified configuration information that might be required.
6) record the necessary driver configuration, and go to 3).
So what we need is a convention whereby the hotplug framework activates a GUI component talking to the user somewhere on the network to get the configuration data required, and a way to communicate that configuration information back to the hotplug system to record for future use (and completion of the first hot plug event for that device).
So the hotplug scripts (running as root) have to be able to initiate the GUI talking to the user, and get data back from there. And it isn't necessarily on the same system, as hotplug is not all about human interface
devices: it is also used for disk drives, tapes, etc, and eventually pluggable processors, memory etc.
So we have two problems:
o A convention of how to know who is administering this system. It may be this is something just for the hotplug folks to worry about.
o How to securely get the right configuration back and forth from the user;
this is the authentication problem, in concert with how to get data back and forth...
- Jim
Quoted 10 lines
There's no reason at all that the configuration GUI has to automatically have root privileges; I would tend to expect something along the lines of:
A new device "USB Magic Camera" has been detected. Please enter the root password to configure this device:
..............
Quoted 4 lines
[ Cancel ] [ OK ]
Regards,
Owen
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines · Jim Gettys
We need a secure, interoperable way for configuration scripts running as root to pop up configuration GUI's on user's servers, and we need it soon (yesterday), as hot-plug is now a reality on Linux systems....
Handling this for the local case is first priority, but we should give some thought about the possibility that the administrator's display is somewhere else in the network (e.g. we're configuring a server system's hotplug event, so the admin is elsewhere).
Is this really what "we" need?
Having stuff "pop up" when certain event occur is probably very nice in many situations, but there are good reasons to why this kind of stuff only happens in the windoze world. You need to, for example, ask yourself the following questions:
Who is the "administrator"?
What if there is no "administrator" logged in? What if there's several "administrators" logged in? How to you distinguish interactive from non-interactive
"administrator" logins?
How do you even know if the "administrator" is running X?
What happens if the "administrator" isn't running X?
How do authenticate with the "administators" display?
How do you know if the "administrators" X session is secure? If it isn't, is it still appropriate to pop up a configuration GUI on
the "administrators" display?
IMHO, interactive configuration needs to be explicitly invoked by the administrator whether or not we're talking about configuring hot-pluggable devices. Any configuration taking place when a hot-plug device becomes available needs to be non-interactive and should be limited to picking up a configuration prepared on beforehand or a default (secure) minimum configuration.
The way the current pcmcia configuration takes place is, IMHO, The right way.
By the way, please don't cross-post excessively like this...
Signature · 7 lines
Christer Palm _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
For more information about how hotplugging works today, see http://linux-hotplug.sourceforge.net/ ... the "overview" link should be informative, and the section on full automation versus user input relates to this discussion. So far there's no user input, and many subsystems don't hotplug yet. That means that a lot of things are left undone.
Quoted 5 lines
So what we need is a convention whereby the hotplug framework activates a GUI component talking to the user somewhere on the network to get the configuration data required, and a way to communicate that configuration information back to the hotplug system to record for future use (and completion of the first hot plug event for that device).
I tend to think of the hotplug system as being an interface to the native system administration mechanism, so things like print spooler setup don't get sucked in to it. FWIW.
Both will need more work to cleanly handle things like plugging in a USB printer, and getting it set up without the user needing to grot around in some quirky sysadmin UI to find the "USB printer setup" section (and then fill it in with information that's already available to the system if it were smart enough to ask for it :).
Quoted 3 lines
So we have two problems:
o A convention of how to know who is administering this system. It may be this is something just for the hotplug folks to worry about.
And, unfortunately, each Linux distro's sysadmin tools.
Quoted 3 lines
o How to securely get the right configuration back and forth from the user; this is the authentication problem, in concert with how to get data back and forth...
Well, authorization -- not all systems are "closed" to the extent that only authorized users can be authenticated! :)
- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
"> " = "Christer Palm" <[email protected]>
"> > " ="Jim Gettys" <[email protected]>
Quoted 5 lines
Quoted 3 lines
We need a secure, interoperable way for configuration scripts running as root to pop up configuration GUI's on user's servers, and we need it soon (yesterday), as hot-plug is now a reality on Linux systems....
Is this really what "we" need?
Yes, with flexibility. Essentially every Linux box out there that's serving as a single-user workstation would benefit from this. It's a fairly basic usability issue for non-expert end-users. We aren't dealing with hardware of ten years ago, where dynamic reconfiguration was only for extremely high end systems.
And if you look at this as an issue for larger systems, it's clear that "hot" reconfiguration is critical for preserving uptime; just think of hotplug events as configuration management alerts. Though in that case a lot more intelligence needs to go into choosing whether (and where) to present any GUI, as noted in your questions.
Quoted 3 lines
Having stuff "pop up" when certain event occur is probably very nice in many situations, but there are good reasons to why this kind of stuff only happens in the windoze world.
And Macintosh ... basically, that single-user workstation model, which defines the "mass market". There are a lot of folk who are working to make sure the Linux community doesn't repeat the mistakes of the UNIX (hardware) vendor community, so that Linux {desk,lap,palm,...}top solutions remain economically viable.
- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 17 lines · David Brownell
"> " = "Christer Palm" <[email protected]>
"> > " ="Jim Gettys" <[email protected]>Quoted 6 lines
Quoted 4 lines
We need a secure, interoperable way for configuration scripts running as root to pop up configuration GUI's on user's servers, and we need it soon (yesterday), as hot-plug is now a reality on Linux systems....
Is this really what "we" need?
Yes, with flexibility. Essentially every Linux box out there that's serving as a single-user workstation would benefit from this. It's a fairly basic usability issue for non-expert end-users. We aren't dealing with hardware of ten years ago, where dynamic reconfiguration was only for extremely high end systems.
Quoted 3 lines
And if you look at this as an issue for larger systems, it's clear that "hot" reconfiguration is critical for preserving uptime; just think of hotplug events as configuration management alerts.
The issue is not whether dynamic, "hot", reconfiguration should be provided or not. That is already provided by the Linux kernel module paradigm and is basically identical to the way dynamic reconfiguration is handled in the "extreme high end systems" you're referring to.
The issue really boils down to whether a system-initiated reconfiguration event should be allowed to initiate administrator interaction.
Compare this to the package-provided configuration scripts used in various software packaging schemes. For many reasons, they cannot be allowed to do user interaction. Still, software installation under the windoze environment is very centered around package-provided user interaction, which, although "user-friendly", also _severely_ limits the flexibility of software installation.
So let's try to not confuse those things.
IMO, this is the simple and straightforward solution to provide what you're looking for:
1) Any changes detected in the hardware configuration would fire a
configuration script.
2) That configuration script would do whatever is needed to introduce
the device to the system, such as loading the corresponding kernel modules, and pick up and apply any default or persistant configuration, etc. All without any user interaction. This would run as root.
So far, this resembles the way things currently work in, for example, the PCMCIA subsystem. What follows is what you need to add...
3) The introduction of a new device fires an event through some
generic well-known framework.
4) A user-level utility started by the administrator, which could be X
based, would pick up the event and display the pop-up that would notify him of the configuration change and allow him to take appropriate action to (re-)configure the device, or in the case of a device that is not known to the system, allow him to install device support software.
The user level utility could be SUID root and do its own authentication (for example, checking if the user is the console owner) to allow a regular non-root user to run it. To avoid confusion about who should receive the configuration "alert", the event framework should probably only allow a single listener.
Ideally, the configuration changes themselves should occur through a generic interface so that the pop-up would not have to call any external procedures. There's a risk of crippling the flexibility of the user interface in that way, but it would remove the need for the device support software to provide any user-interface stuff. This would make it possible to change and enhance the user interface part without having to re-write any of the device support stuff, it will guarantee consistency in the user interface, and it would be much easier to avoid security problems. In this case, permissions could be handled by the generic configuration interface, and the user level utility would not have to be SUID root.
Signature · 7 lines
Christer Palm _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines · [email protected] (Jim Gettys) writes:
Owen:
This is certainly true: but not sufficient...
I wasn't trying to give a complete solution, just trying to dispell any notion that interactivity with hotplug events would necessarily involve popping up a root shell on the current login users desktop :-)
Quoted 25 lines
Here's the sequence as I understand it:
1) new device gets plugged in.
2) system has to figure out what driver to use.
3) if it has seen it before, presumably it can consult some sort of database to help hook it up, both by whatever driver parameters it needs, and to hook it up to a user level program it activates. We're done at this point.
4) if the system has never seen it before, we have to somehow ask the user what to do.
5) the driver finally gets loaded, with the user specified configuration information that might be required.
6) record the necessary driver configuration, and go to 3).So what we need is a convention whereby the hotplug framework activates a GUI component talking to the user somewhere on the network to get the configuration data required, and a way to communicate that configuration information back to the hotplug system to record for future use (and completion of the first hot plug event for that device).
So the hotplug scripts (running as root) have to be able to initiate the GUI talking to the user, and get data back from there. And it isn't necessarily on the same system, as hotplug is not all about human interface
devices: it is also used for disk drives, tapes, etc, and eventually pluggable processors, memory etc.
Quoted 6 lines
So we have two problems:
o A convention of how to know who is administering this system. It may be this is something just for the hotplug folks to worry about.
o How to securely get the right configuration back and forth from the user;
this is the authentication problem, in concert with how to get data back and forth...
I think it probably makes sense to reduce the communication to one of notification.
- In response to the hotplug event, if the device can't be configured automatically, record that data, and notify the appropriate user(s).
- When the user gets the notification, present them with the option to run a config tool, which would then complete the configuration.
This has various advantages; principally.
- It's flexible (notification could be sending an email saying "go to this URL to configure your new printer.)
- It reduces the authentication problem to a known and solved problem. (Can user X do Y.)
In terms of how to do notification, you can go from simple to complex:
- Watch a file in a timeout. (We had hotplug for USB storage devices in Red Hat 7.1 working quite nicely by watching /etc/fstab for changes; kudzu added new entries in response to hotplug events. magicdev noticed the changes, signaled mc which added icons on the desktop.)
- Local messaginge daemon; if you keep it simple, use unix perms, don't worry to much about quality-of-service, etc, it doesn't need to be a big project.
- Networked based messaging; jabber, etc. May make sense to piggyback off an existing solution. But then you get the problem that you are talking about something big that everybody needs to adopt.
Anyways, just my random thoughts on the issue. My main observation is that I think it's a mistake to think of this as "hotplug script pops up a configuration dialog" even if it might appear like that to the user in the simplest case.
Regards,
Owen
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 30 lines · Jim Gettys
Fundamentally, we have no convention right now for any client (root or not) to connect to an X server except on initiation of the user (unless the user is silly enough to disable authentication entirely.
This is an generic X issue (how to delegate authorization to connect). There is the xauth mechanism, not very secure, but no convention on its use in these circumstances. There is also support for kerberos, which is reasonably secure when used properly. And there is SSH, which has never been integrated into X's world cleanly (and probably should be). And there is Owen's scheme for
some sort of server process, but this presents much the same fundamentalsecurity/authentication/authorizationproblem as well.I don't have a preconcieved
notion of what the correct solution is; I'm not even very familiar with the possibilities.Certainly, I want no user intervention as much of the time as possible, but we also need a hotplug design which allows for user intervention at the time of first use in cases where it may be necessary. The hotplug script design needs to allow for this, even if it is not the usual case. And there is need to automatically run GUI based programs, even after configuration (automatically downloading images off your camera, for example).
Personally, I find it very frustrating to have to go looking for a configuration tool before I can use some hardware: this is not something a (mere mortal) user knows in advance, and so don't believe the right thing
to do is necessarily nothing (though for much hardware this may be the correct
answer, it isn't for most casually used hardware).
Quoted 8 lines
We can certainly split this discussion to the different communities if people think that is best, but I wanted to get the problem aired; there is a problem for each community to mull over at the core of this problem.
And someone who sends mail from an address "nogui" certainly has a strong opinion on the topic, which may not be universal :-;.
- Jim
Jim, if the user is logged in so is the rest of the user interface. Why not have a monitoring program (like console) that watches the hotplug events and invokes corresponding configuration program ? This would also allow for various user environments to customize configuration tools to match their look.
Vladimir Dergachev
Quoted 8 lines
--
Jim Gettys
Cambridge Research Laboratory
Compaq Computer Corporation
[email protected]
Quoted 5 lines
_______________________________________________
Xpert mailing list
[email protected]
http://XFree86.Org/mailman/listinfo/xpert
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 7 lines
Jim, if the user is logged in so is the rest of the user interface. Why not have a monitoring program (like console) that watches the hotplug events and invokes corresponding configuration program ? This would also allow for various user environments to customize configuration tools to match their look.
That solution is not in itself sufficient. You might not want everybody to see all hotplug events.
Regards
Oliver
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines · Oliver Neukum
Quoted 6 lines
Jim, if the user is logged in so is the rest of the user interface. Why not have a monitoring program (like console) that watches the hotplug events and invokes corresponding configuration program ? This would also allow for various user environments to customize configuration tools to match their look.
That solution is not in itself sufficient. You might not want everybody to see all hotplug events.
And what would the problem be with using an event distribution mechanism that would require the listener to have certain privileges?
Signature · 7 lines
Christer Palm _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Jim, if the user is logged in so is the rest of the user interface. Why not have a monitoring program (like console) that watches the hotplug events and invokes corresponding configuration program ?
Actually one of the goals of the hotplug framework is to avoid requirements to have Yet Another Monitoring Daemon hanging around wasting resources ... likewise, to avoid needing to start the apropriate magic program before plugging in devices.
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
This would also
allow for various user environments to customize configuration tools to match their look.
... of course, if the events could get fed into some existing daemon (via authenticared RPC, SSH-secured channel, or whatever) that
kind of appearance-agnostic behavior becomes simpler! The issue
then becomes how hotplug identifes and accesses the channel, and who will modify what existing daemons. :)
Quoted 5 lines
Quoted 2 lines
That solution is not in itself sufficient. You might not want everybody to see all hotplug events.
And what would the problem be with using an event distribution mechanism that would require the listener to have certain privileges?
Another of the goals classic end-user "usability". Remember that the original problem was how to fire up an unprivileged tool ... not all hotplug events imply any need for privilege. Users initiate hotplug events with just physical access privileges. When the device software has already been set up, additional privilege shouldn't be needed.
- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines · David Brownell
Actually one of the goals of the hotplug framework is to avoid requirements to have Yet Another Monitoring Daemon hanging around wasting resources ... likewise, to avoid needing to start the apropriate magic program before plugging in devices.
I wouldn't call using a few K's of memory a waste of resources. The program does of course not necessarily has to be started explicitly by the user. It would be added to whatever "autostart" mechanism the user interface in question would use.
Quoted 11 lines
Quoted 4 lines
Quoted 1 line
And what would the problem be with using an event distribution mechanism that would require the listener to have certain privileges?
Another of the goals classic end-user "usability". Remember that the original problem was how to fire up an unprivileged tool ... not all hotplug events imply any need for privilege. Users initiate hotplug events with just physical access privileges. When the device software has already been set up, additional privilege shouldn't be needed.
Practically all desktop Linux distributions associates these kind of things with console ownership. If you're on the console, you are allowed access the graphics adapter, audio, floppy, cdrom, etc. devices. I don't see a problem with hotplug management following the same scheme. In fact , it _should_ follow the same scheme - wouldn't it be quite stupid if you could manage hot plug devices, but not access the floppy or cdrom?? Or does this concept have to change, too?
Signature · 7 lines
Christer Palm _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines
Quoted 4 lines
Actually one of the goals of the hotplug framework is to avoid requirements to have Yet Another Monitoring Daemon hanging around wasting resources ... likewise, to avoid needing to start the apropriate magic program before plugging in devices.
I wouldn't call using a few K's of memory a waste of resources.
Most examples I've seen start at closer to an M or two, which does matter. I'd call such issues workable, though obesity in GUI frameworks has sometimes reached criminal levels.
Re access rights:
Quoted 4 lines
Practically all desktop Linux distributions associates these kind of things with console ownership. If you're on the console, you are allowed access the graphics adapter, audio, floppy, cdrom, etc. devices. I don't see a problem with hotplug management following the same scheme.
Right, though it's not quite that simple even there.
The "single user desktop" model is well known to be the one which is relatively straightforward to address -- and arguably hits the "95% of end users" case here. So long as one can kick in a "no gui" mode for servers, and do something intelligent in the case of multi-gui systems, that's a good place to start.
- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines · Oliver Neukum
Quoted 7 lines
Jim, if the user is logged in so is the rest of the user interface. Why not have a monitoring program (like console) that watches the hotplug events and invokes corresponding configuration program ? This would also allow for various user environments to customize configuration tools to match their look.
That solution is not in itself sufficient. You might not want everybody to see all hotplug events.
I think it is. It is not very hard to to setup permission policy.. For example you can only allow this to users who are able to login at the console and not remotely. (By using GiveConsole/TakeConsole for xdm/kdm/gdm for example).
I am sure you can get by with usual permissions based fifo in most if not all situations. However it is not difficult to devise a way more generic scheme than would ever be useful..
Say: have /var/hotplug/fifo/classX be fifos for different classes of events. Have /sbin/hotplug filter incoming events and echo them into these fifos. Have these fifos only accessible by root (or whatever /sbin/hotplug runs under). Write a simple daemon that monitors classX fifos and also /var/hotplug/fifo/command and passes the events onto a Unix socket on localhost.. make it named if like :) /var/hotplug/events for example.
So, GiveConsole determines whether the user deserves access to classX events and if yes echo something like this:give_access classX 'xserver full displayname' A45GF_md5_random into command fifo and sets "CLASSX_ACCESS_CODE" property on the root window to A45GF_md5_random (with X being replaced by the class number).
The monitor app reads off these codes and passes them the daemon which then uses them to actually enable passthru of messages.
When the server closes the root window gets destroyed and TakeConsole echos the following:revoke_access 'xserver full displayname'
to allow the daemon to discard codes that will no longer be used.
So, here, it was long and overcomplicated but I don't see how you may want something more flexible than this.
Vladimir Dergachev
Quoted 4 lines
Regards
Oliver
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 7 lines · Christer Palm
Quoted 6 lines · Oliver Neukum
Quoted 5 lines
Jim, if the user is logged in so is the rest of the user interface. Why not have a monitoring program (like console) that watches the hotplug events and invokes corresponding configuration program ? This would also allow for various user environments to customize configuration tools to match their look.
Quoted 5 lines
Quoted 2 lines
That solution is not in itself sufficient. You might not want everybody to see all hotplug events.
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.
Regards
Oliver
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · David Brownell
The "single user desktop" model is well known to be the one which is relatively straightforward to address -- and arguably hits the "95% of end users" case here. So long as one can kick in a "no gui" mode for servers, and do something intelligent in the case of multi-gui systems, that's a good place to start.
Not quite sure what you mean by "multi-gui systems".
Supplying a solution for "single user desktop" and "no gui servers" will satisfy *almost* everyone.
However installing "single user desktop" on a classroom full of workstations runs the risk of being insufficently secure. Although it may be a minority market, screwing it up could be very bad for everyones reputation.
Even having a "classroom workstation" option, could be dangerous if it doesn't have the features of "single user desktop", since some people will install the full-featured version however much you warn them of the pitfalls.
Besides it is much harder to bolt on security ofterwards.
Signature · 8 lines
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [email protected] http://www.dpmms.cam.ac.uk/~werdna _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines · David Brownell
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Jim, if the user is logged in so is the rest of the user interface. Why not have a monitoring program (like console) that watches the hotplug events and invokes corresponding configuration program ?
Actually one of the goals of the hotplug framework is to avoid requirements to have Yet Another Monitoring Daemon hanging around wasting resources ... likewise, to avoid needing to start the apropriate magic program before plugging in devices.
You could have the demon started by inetd.
[..]
Quoted 8 lines
Quoted 2 lines
And what would the problem be with using an event distribution mechanism that would require the listener to have certain privileges?
Another of the goals classic end-user "usability". Remember that the original problem was how to fire up an unprivileged tool ... not all hotplug events imply any need for privilege. Users initiate hotplug events with just physical access privileges. When the device software has already been set up, additional privilege shouldn't be needed.
Not all users are equal in this regard. Eg. a FibreChannel network might be quite extensive.
Regards
Oliver
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines · Oliver Neukum
Quoted 3 lines
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??
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.
Signature · 7 lines
Christer Palm _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 12 lines · Christer Palm
Quoted 8 lines · Oliver Neukum
Quoted 3 lines
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.
Quoted 8 lines
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??
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.
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.
Quoted 4 lines
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.
Regards
Oliver
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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
Quoted 14 lines
Sender: [email protected]
From: <[email protected]>
Date: Tue, 5 Feb 2002 12:35:41 +0100 (MET)
To: Christer Palm <[email protected]>
Cc: <[email protected]>,
Vladimir Dergachev <[email protected]>,
Jim Gettys <[email protected]>, David Brownell <[email protected]>, Ryan Shaw <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>
Subject: Re: [Xpert]Re: User-level Tasks in Hotplug Scripts?
-----
On Tue, 5 Feb 2002, Christer Palm wrote:
Quoted 21 lines
Quoted 7 lines
Quoted 5 lines · Oliver Neukum
Quoted 3 lines
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
Quoted 13 lines
Quoted 3 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
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.
Quoted 8 lines
Quoted 5 lines
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
[email protected]
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Hmm, I seem to see a little different side of this issue. In PCMCIA hotplug, the user sticks in the card, and it says "beep-beep" if it loads the driver and runs the init script, or "beep-blecch" otherwise. That's the extent of the GUI. I think we should be starting from that end, not the specific beeps, but with the idea of a very simple interface with minimal user involvement.
When the card doesn't load, the person does "su root" (if privileged) and starts mucking around with the card database, and even recompiling drivers to add the PCI ID of the "you get what you pay for" rebrand card he (I) bought. I'm not saying that some GUI help for the sysop is bad, but it's going to be able to cover only limited and routine operations. I think the main focus for the current discussion started out as a user-level issue, starting a special init script that downloaded and displayed some photos, not assistance for the sysop.
So one of our students in the lab plugs in his Rio or iPod into USB to copy some songs to it. If we have the drivers set up, fine, it works, no GUI needed. If we don't, you can be sure that we aren't going to offer him a GUI so he can download nekulturny lyrics (that he probably didn't pay for) in *our* lab.
James F. Carter Voice 310 825 2897 FAX 310 206 6673
UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: [email protected] http://www.math.ucla.edu/~jimc (q.v. for PGP key)
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel