From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dr Andrew C Aitchison Date: Sun, 03 Feb 2002 08:43:05 +0000 Subject: Re: [Xpert]Re: User-level Tasks in Hotplug Scripts? Message-Id: List-Id: 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, 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.... 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. > 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. > 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. > - Jim > > > Sender: linux-hotplug-devel-admin@lists.sourceforge.net > > From: David Brownell > > Date: Fri, 01 Feb 2002 15:58:31 -0800 > > To: Ryan Shaw , > > linux-hotplug-devel@lists.sourceforge.net > > Subject: Re: User-level Tasks in Hotplug Scripts? > > ----- > > > 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. > > > > > > > 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.log 2>&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. > > > > - Dave > > > > > > _______________________________________________ > > 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 > _______________________________________________ > Xpert mailing list > Xpert@XFree86.Org > http://XFree86.Org/mailman/listinfo/xpert > -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge A.C.Aitchison@dpmms.cam.ac.uk http://www.dpmms.cam.ac.uk/~werdna _______________________________________________ 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