Re: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[Dr Andrew C Aitchison <A C Aitchison dpmms cam ac uk>]

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 <david-b pacbell net>
> > Date: Fri, 01 Feb 2002 15:58:31 -0800
> > To: Ryan Shaw <ryan shaw stanfordalumni org>,
> >         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