From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dmitry Yu. Bolkhovityanov" Date: Mon, 04 Feb 2002 06:02:32 +0000 Subject: 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 On Sat, 2 Feb 2002 12:55:41 -0800 (PST), Jim Gettys wrote: > 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.... > > 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). > > 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. Hi! Maybe the following scheme would suffice: - There's a "hotplug daemon", which gets hotplug events from the kernel. This daemon establishes a listening socket with port<1024. - When an X server is started by a user which wants to deal with hotplug events, the GUI launches a client, let's name it "hotplug commander". The commander connect()s to the daemon and tells him that it wants to receive hotplug events of this, this and this type. - When an actual hotplug occurs, the daemon sends short information packet to all interested commanders. If that action requires some responce from a user, then appropriate password is asked and sent back to the server along with config info (as a variant: the password is asked upon first action, and later that TCP connection is treated by the daemon as "authorized"). So, the pros: - We have an ability to send hotplug events over a network (but by default the socket can be bound to localhost). - The technology of writing secure network daemons is well known (access control, dealing with "bad" clients, secure channels, etc.). - No problem of finding out administrator's display and authenticating to it. - The "hotplug commanders" can be not only GUI apps, but also text-based and even just daemons/robots. BTW, should I cc: to some more addresses? _________________________________________ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia _______________________________________________ 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