User-level Tasks in Hotplug Scripts?

Hello,

I have USB hotplugging set up on my machine so that pictures are automatically downloaded from my camera (via jphoto) when I plug it in.

I would like to have the script that is run when hotplug detects my camera launch nautilus as well, as it is my image browser of choice.

First question: Is the hotplug script the right place for this? If not, where is?

Second question: If the hotplug script is the right place, why doesn't the following work?

Hotplugging scripts are run as root, so I have the following line to launch nautilus:

su - ryan -c "nautilus --display=:0.0 > /home/ryan/nautilus.log 2>&1" &

This works if I just run the script as root, but it doesn't work when the script is initiated buy the actual hotplugging. (Pictures are downloaded OK, just nautilus doesn't start.)

I've attached my hotplug script below.

Any light you could shed would be greatly appreciated.

Ryan

/etc/hotplug/usb/jphoto
------------------------------------------------------------
#!/bin/sh

# if present, images are automatically downloaded
DOWNLOAD=/home/ryan/images

# where jPhoto executable is installed
JPHOTO=/usr/local/bin/jphoto

# download images and launch viewer
if [ -d $DOWNLOAD ]; then
    cd $DOWNLOAD
    (echo '*** '$(date); $JPHOTO images --directory .; echo '') \
        >> images.$(date '+%Y-%m.%d')
    chown ryan:ryan *
    su - ryan -c "nautilus --display=:0.0 $DOWNLOAD > /home/ryan/nautilus.log 2>&1" &
fi

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Sure. Setup scripts are often used to do such stuff.

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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.
- Jim

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Is there anything wrong with the simplistic approach of having a demon listening on a socket? If you want it generic, you have to use generic means of communication.

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

-

You don't want to pass out permission to access your X server to anyone who happens to ask for it (if you do, you've compromized everything, or go down into compartmentalized workstation hell, someplace where we went 10 years ago and found fundamentally painful).
So the issue is fundamentally one of authenticating
the configuration GUI's process to the X server to allow connection.

The other issue is how to associate the correct X display server with the hotplug event, so that the correct user is notified. As I pointed out, this is not necessarily local to the machine where the hotplug occurred.
- Jim

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

There's no reason the listening demon has to be part of X, or is there ? An interrested user would start a task listening upon login.

Regards
Oliver

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

There are several ways to factor the connection problem, and that isn't an issue in all of them ... you may be assuming the hotplug agent calls something that tries to talk X directly. That's not the only solution.

My original post mentioned one alternative, which doesn't go that route (and doesn't have that problem): talking to some intermediary (perhaps using CORBA) which starts with that X server (or whatever) privilege. I seem to recall many X-based desktops assuming such a component, to handle things like "start the right app for this document". Very much like "start the right config gui for this alert."

Admittedly there's an analagous problem in that case. The hotplug agent runs as root, and it had sure better be able to authenticate to that intermediary. I'm just saying it's not "fundamentally" an X11 authentication issue.

When I've thought about this before, I've ended up with the notion that the desktop needs some way to say "notify <agent addr='...'/> when ..." as it starts up, and for that information to be available to hotplug agents (running as root) in some trustworthy manner.

I think that's what Oliver was saying when he suggested starting some server at user login.

If that "notify <agent addr='...'/> when ..." stuff generalizes, and the hotplug agent knows how to interpret it, there's no reason it wouldn't work neatly over a network. It could be an X11-specfic thing, though I'd certainly prefer that not be a requirement.

And if the convention whereby the hotplug agents access that data is reasonable, it would expose whether a given system is a "single user PC/Workstation" configuration, or a multi-user one that might need more intelligence to dispatch such events to the listeners.

In the cases where the remote (or even local) agent can handle the configuration event/alert without needing any user interaction at all, I'd think it would be desirable to design things up so that X isn't a hard requirement.

- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Note: sorry for all the CC's. i've lost track of who is on what list. :P

The listener should definitely be left to the desktops, or as a background process as login in the case of a non-X environment.

The hotplug backend might implement a generic configuration language. We've done this with gPhoto by using some common widgets and it works really well. we use it for configuration of camera settings (exposure, lens modes, etc...). It supports menus, lists, radio buttons, text entries, etc... all the standard widgets.

Perhaps it would all work something like this:

1) Desktop listener listens on a port/fifo/pipe/whatever...
2) User plugs device
3) Hotplug runs appropriate script ("init"). init would be whatever hotplug does now.
4) Hotplug then runs script with "get_config" arg to retrieve the configuration 'widgets' (written to stdout)
5) Hotplug then writes the configuration widgets to the port/fifo/pipe/whatever, prefixed by a header that describes which device this is for. For now, hotplug considers itself done.
6) User select settings, selects OK.
7) Desktop listener writes the updated configuration widgets to the port/fifo/pipe/whatever
8) Hotplug then reads in the updated configuration widgets, then calls the appropriate hotplug script with "set_config" arg (config items are read from stdin).
9) Hotplug script handles the rest.

Now, if multiple hotplug scripts try to claim a device, perhaps hotplug will write a configuration that lets the user select which script to use, and then it continues with the chosen hotplug script. This is something that came up when i brought this up earlier: what if jphoto and gphoto both want to use the device? just let them run, or let the user decide? if there is no listener, then perhaps they all should run. if there is a listener, let the user decide.

security? make sure you only accept connections from a user who is locally logged in (not remote), unless you configure it differently to allow remote connections. this just needs to be developed further in a USB security model. (local user = full permissions on all USB devices?) :P

-=Scott Fritzinger
The gPhoto project
www.gphoto.org

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

No. Look at the new input subsystem in 2.5. It should allow you to have different USB keyboards and mice assigned to different X displays, all attached to one machine. So if one user plugs in a digital camera into their keyboard's USB hub, who is the local user? All users of the machine?

It gets pretty tricky :)

thanks,

greg k-h

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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 fundamental security/authentication/authorization problem 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).

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 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

I have a distantly related application which does security checksums (as root) and displays the result to whoever happens to be logged in, piping it to xmessage. Being root, with authority to read any file, I steal the X-server's own authorization file. Here's the code, leaving out two or three details that bypass this if X happens to be turned off:

for f in /etc/X11/xdm/authdir/authfiles/A:0* ; do
XAUTHORITY=$f
done
export DISPLAY=:0.0
export XAUTHORITY
xmessage -title "Daily Housekeeping" -timeout 900 -file /tmp/report.txt

The loop is done because an accident might leave a stale auth file, and I'd rather have it fail to auth than get a syntax error.

In your case, I'd suggest doing an imitation of xdm -- copy the auth file to a file in /tmp owned by you and mode 600, and XAUTHORITY=/tmp/thatfile. Then do the "su". Then if your kid in middle school is using your machine, he/she can plug in the camera and see the pics, but can't do much damage through the X authorization. (And, since the kid is the console user, the auth file properly belongs to him, so essentially you've stolen it from him, not him from you.)

I'm not suggesting this as a general solution, as for a Windoze-ish GUI to select drivers and config parms, and particularly, the security implications would have to be thought through *very* carefully in a public lab environment, but for a single-user or family situation it's probably sufficient.

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

No single convention, no. And I don't know what's current, but I've certainly worked with systems where X11 desktop frameworks have one application registered in a network naming system, acting as an authorized intermediary for other clients. The other clients weren't allowed to directly contact users' X11 servers, but that intermediary either implemented or forked off components that _could_ do so.

Who has a good summary of what current versions of Gnome and KDE do along those lines -- anything? I see /tmp/orbit-* files on my current Linux system, UNIX domain sockets rather than TCP ones. That makes me suspect at least Gnome doesn't yet have a widely interoperable solution of this type.

I think it clearly does, though implementation is lacking. None of these problems is novel, all have been solved repeatedly by groups who've implemented desktop frameworks under X11. The transport choice gets political though: everyone has their favorite RPC-du-jour (often wagged by significant infrastructure tails).

If there's no single standard yet, having the X session startup save a /var/run file with some daemon's transport address understood by the hotplug framework would suffice. For non-desktop systems, it could point to a remote sysadmin agent. The requests delivered there would not necessarily correspond to hotplug events.

That's one of my canonical examples. Though when it's a webcam, not a still image camera, "downloading" means firing up the user's preferred video tool ... :)

- Dave

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

i didn't realize this was such a hot topic!

i tried this--no dice. but i'm starting to think that this is specifically a nautilus problem. just doing

su - ryan -c "$PROGRAM --display=:0.0"

in the hotplug script (without setting XAUTHORITY) works for about everything i've tried, including gnome apps, but not for nautilus. unfortunately, nautilus is not printing anything to stdout or stderr, so i can't figure out what it is missing, and no one on the nautilus-dev list seems to know either.

anyway, thanks for the suggestions. i'm interested to see what comes out of the discussion i unintentionally sparked.

ryan

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I second Dimitry's statements. This problem is *not at all* X-specific. There are already lots of PDAs around that use direct frame buffer access for instance. Or I might want to use the console only. And then it is not even Linux/Unix-specific. I might want to configure my hotplugged device from an entirely different OS I happen to have a client for. So any X-specific solution is IMHO a dead end.

Assuming we have a daemon (which can be rather slim BTW). How about the following scheme:

- Client has to be started. Could be done by user's desktop environment as default. User has option to turn it off.

- Client registers with hotplug-server. Optionally, the client has to authenticate itself when registering. By default it requests to get all hotplug events.

- Server sees some hotplug action and checks who should be notified. Optionally it also checks who would be allowed to see this event. Server then notifies all clients that meet all necessary criteria.

- Client receives notification and opens a dialog with appropriate options according to the event. The dialog may be informative only. Every dialog offers the option to unregister for this type of event/device/whatever.

The main problem now is to have a suite of configuration protocols as well. I gather that should be easy with printers through CUPS (WWW browser access) and scanners through SANE (you typically configure the scanner only when using it).

Best regards,
Marcus

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I agree entirely. There are two issues here: the generic hotplug framework, and an X specific problem. The generic framework needs to work with any mechanism (X, other display systems, SNMP agents, etc.).

X itself has the generic problem of how to delegate connection authority; I suspect that existing mechanisms (xauth, kerberos, or doing something with SSH) will serve fine here, with conventions on how to use them.

We need this delegation not only for hotplug, and various other situations (e.g. migration of applications, etc.) to come up with X over the next year or two.

Other than needing solutions that play together (hotplug and X), they are separable problems. Now that the issues have been aired somewhat, we could split the discussion between parties and only again hit all lists when people have concrete solutions to propose.

Note that any daemon solution has similar authorization problems related to that found by X programs wanting to serve this purpose. Again, figuring out who is authorized to do configuration is key. It is this transition from priviledged to unpriviledged (but authenticated) that is the trick.

As this stews around my brain, I keep coming back to things like LDAP and kerberos, for the network transparent case. But I need to do more homework, though was hoping someone on these lists might have enough experience with them to propose something. I guess I'll go chat with my IETF buddies about the issue; it is a larger one than hotplug, and in an area I've never worked in.
- 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