From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christer Palm Date: Sun, 03 Feb 2002 23:49:12 +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 David Brownell wrote: > "> " = "Christer Palm" > "> > " ="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.... >>> >>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. 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. -- Christer Palm _______________________________________________ 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