User-level Tasks in Hotplug Scripts?

User-level Tasks in Hotplug Scripts?

[Ryan Shaw]

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: User-level Tasks in Hotplug Scripts?

[David Brownell]

> 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

Re: User-level Tasks in Hotplug Scripts?

[Jim Gettys]

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

> 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

_______________________________________________
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

Re: User-level Tasks in Hotplug Scripts?

[Oliver Neukum]

On Saturday 02 February 2002 21:55, 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....

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: User-level Tasks in Hotplug Scripts?

[Jim Gettys]

-
> From: 520047054719-0001@t-online.de (Oliver Neukum)
> Date: Sat, 2 Feb 2002 23:02:11 +0100
> To: jg@pa.dec.com (Jim Gettys), David Brownell <david-b@pacbell.net>
> Cc: Ryan Shaw <ryan.shaw@stanfordalumni.org>,
>         linux-hotplug-devel@lists.sourceforge.net, wm-spec-list@gnome.org,
>         xpert@xfree86.org
> Subject: Re: User-level Tasks in Hotplug Scripts?
> -----
> On Saturday 02 February 2002 21:55, 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....
>
> 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.
>

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: User-level Tasks in Hotplug Scripts?

[Oliver Neukum]

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

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: User-level Tasks in Hotplug Scripts?

[David Brownell]

> So the issue is fundamentally one of authenticating
> the configuration GUI's process to the X server to allow connection.

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.


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

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: User-level Tasks in Hotplug Scripts?

[Scott Cuyle Fritzinger]

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

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

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: User-level Tasks in Hotplug Scripts?

[Greg KH]

On Sat, Feb 02, 2002 at 04:58:18PM -0800, Scott Cuyle Fritzinger wrote:
> 
> 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

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: User-level Tasks in Hotplug Scripts?

[Dmitry Yu. Bolkhovityanov]

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

Re: User-level Tasks in Hotplug Scripts?

[Jim Gettys]

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
jg@pa.dec.com


_______________________________________________
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

Re: User-level Tasks in Hotplug Scripts?

[Jim Carter]

On Fri, 1 Feb 2002, Ryan Shaw wrote:
> 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.
> ...
> Hotplugging scripts are run as root, so I have
> the following line to launch nautilus: [which won't start]
>
> su - ryan -c "nautilus --display=:0.0 > /home/ryan/nautilus.log 2>&1" &

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: jimc@math.ucla.edu    http://www.math.ucla.edu/~jimc (q.v. for PGP key)


_______________________________________________
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

Re: User-level Tasks in Hotplug Scripts?

[David Brownell]

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

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.


> Certainly, I want no user intervention as much of the time as possible, but
> 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.

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.


> And there is need to automatically run GUI based programs, even after
> configuration (automatically downloading images off your camera, for
> example).

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: User-level Tasks in Hotplug Scripts?

[Ryan Shaw]

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

On Mon, 4 Feb 2002 11:28:51 -0800 (PST)
Jim Carter <jimc@math.ucla.edu> wrote:

> On Fri, 1 Feb 2002, Ryan Shaw wrote:
>
> > Hotplugging scripts are run as root, so I have
> > the following line to launch nautilus: [which won't start]
> >
> > su - ryan -c "nautilus --display=:0.0 > /home/ryan/nautilus.log 2>&1" &
> 
> 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 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: User-level Tasks in Hotplug Scripts?

[Marcus Harnisch]

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: User-level Tasks in Hotplug Scripts?

[Jim Gettys]

> Sender: linux-hotplug-devel-admin@lists.sourceforge.net
> From: Marcus Harnisch <marcus.harnisch@gmx.net>
> Date: Wed, 6 Feb 2002 09:30:17 -0500
> To: "Dmitry Yu. Bolkhovityanov" <D.Yu.Bolkhovityanov@inp.nsk.su>
> Cc: xpert@xfree86.org, linux-hotplug-devel@lists.sourceforge.net
> Subject: Re: User-level Tasks in Hotplug Scripts?
> -----
> 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.

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.

> 
> Assuming we have a daemon (which can be rather slim BTW). 
> 

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
jg@pa.dec.com


_______________________________________________
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