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

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

[Dr Andrew C Aitchison]

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


_______________________________________________
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: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[Owen Taylor]

Dr Andrew C Aitchison <A.C.Aitchison@dpmms.cam.ac.uk> writes:

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

There's no reason at all that the configuration GUI has to 
automatically have root privileges; I would tend to expect
something along the lines of:

 A new device "USB Magic Camera" has been detected.
 Please enter the root password to configure this
 device:
           ..............

                            [ Cancel ] [  OK  ]

Regards,
                                        Owen

_______________________________________________
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: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[Jim Gettys]

Owen:

This is certainly true: but not sufficient...

Here's the sequence as I understand it:

1) new device gets plugged in.
2) system has to figure out what driver to use.
3) if it has seen it before, presumably it can consult some sort of database
   to help hook it up, both by whatever driver parameters it needs, and to hook
   it up to a user level program it activates.  We're done at this point.
4) if the system has never seen it before, we have to somehow ask the user
   what to do.
5) the driver finally gets loaded, with the user specified configuration
   information that might be required.
6) record the necessary driver configuration, and go to 3).

So what we need is a convention whereby the hotplug framework activates
a GUI component talking to the user somewhere on the network to get
the configuration data required, and a way to communicate that configuration
information back to the hotplug system to record for future use (and completion
of the first hot plug event for that device).

So the hotplug scripts (running as root) have to be able to initiate the
GUI talking to the user, and get data back from there.  And it isn't
necessarily on the same system, as hotplug is not all about human interface
devices: it is also used for disk drives, tapes, etc, and eventually pluggable
processors, memory etc.

So we have two problems:
    o A convention of how to know who is administering this system.  It may
    be this is something just for the hotplug folks to worry about.
    o How to securely  get the right configuration back and forth from the user;
this is the authentication problem, in concert with how to get data back
and forth...
                                 - Jim


>
> There's no reason at all that the configuration GUI has to
> automatically have root privileges; I would tend to expect
> something along the lines of:
>
>  A new device "USB Magic Camera" has been detected.
>  Please enter the root password to configure this
>  device:
>            ..............
>
>                             [ Cancel ] [  OK  ]
>
> Regards,
>                                         Owen

_______________________________________________
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: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[Christer Palm]

Jim Gettys wrote:

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


Is this really what "we" need?
Having stuff "pop up" when certain event occur is probably very nice in 
many situations, but there are good reasons to why this kind of stuff 
only happens in the windoze world. You need to, for example, ask 
yourself the following questions:

   Who is the "administrator"?
   What if there is no "administrator" logged in?
   What if there's several "administrators" logged in?
   How to you distinguish interactive from non-interactive 
"administrator" logins?

  How do you even know if the "administrator" is running X?

   What happens if the "administrator" isn't running X?
   How do authenticate with the "administators" display?
   How do you know if the "administrators" X session is secure?
   If it isn't, is it still appropriate to pop up a configuration GUI on 
the "administrators" display?

IMHO, interactive configuration needs to be explicitly invoked by the 
administrator whether or not we're talking about configuring 
hot-pluggable devices. Any configuration taking place when a hot-plug 
device becomes available needs to be non-interactive and should be 
limited to picking up a configuration prepared on beforehand or a 
default (secure) minimum configuration.

The way the current pcmcia configuration takes place is, IMHO, The right 
way.

By the way, please don't cross-post excessively like this...

-- 
Christer Palm


_______________________________________________
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: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[David Brownell]

For more information about how hotplugging works today,
see http://linux-hotplug.sourceforge.net/ ... the "overview"
link should be informative, and the section on full automation
versus user input relates to this discussion.  So far there's
no user input, and many subsystems don't hotplug yet.
That means that a lot of things are left undone.


> So what we need is a convention whereby the hotplug framework activates
> a GUI component talking to the user somewhere on the network to get
> the configuration data required, and a way to communicate that configuration
> information back to the hotplug system to record for future use (and completion
> of the first hot plug event for that device).

I tend to think of the hotplug system as being an interface to the native
system administration mechanism, so things like print spooler setup
don't get sucked in to it.  FWIW.

Both will need more work to cleanly handle things like plugging in a
USB printer, and getting it set up without the user needing to grot
around in some quirky sysadmin UI to find the "USB printer setup"
section (and then fill it in with information that's already available
to the system if it were smart enough to ask for it :).


> So we have two problems:
>     o A convention of how to know who is administering this system.  It may
>     be this is something just for the hotplug folks to worry about.

And, unfortunately, each Linux distro's sysadmin tools.


>     o How to securely  get the right configuration back and forth from the user;
>      this is the authentication problem, in concert with how to get data back
>      and forth...

Well, authorization -- not all systems are "closed" to the extent
that only authorized users can be authenticated!  :)

- 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: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[David Brownell]

"> "        =  "Christer Palm" <palm@nogui.se>
"> > "     ="Jim Gettys" <jg@pa.dec.com>

> > 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 this really what "we" need?

Yes, with flexibility.  Essentially every Linux box out there that's
serving as a single-user workstation would benefit from this.
It's a fairly basic usability issue for non-expert end-users.  We
aren't dealing with hardware of ten years ago, where dynamic
reconfiguration was only for extremely high end systems.

And if you look at this as an issue for larger systems, it's clear
that "hot" reconfiguration is critical for preserving uptime; just
think of hotplug events as configuration management alerts.
Though in that case a lot more intelligence needs to go into
choosing whether (and where) to present any GUI, as noted
in your questions.


> Having stuff "pop up" when certain event occur is probably very nice in 
> many situations, but there are good reasons to why this kind of stuff 
> only happens in the windoze world.

And Macintosh ... basically, that single-user workstation model,
which defines the "mass market".  There are a lot of folk who
are working to make sure the Linux community doesn't repeat
the mistakes of the UNIX (hardware) vendor community, so that
Linux {desk,lap,palm,...}top solutions remain economically viable.

- 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: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[Christer Palm]

David Brownell wrote:

> "> "        =  "Christer Palm" <palm@nogui.se>
> "> > "     ="Jim Gettys" <jg@pa.dec.com>
> 
>>>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 this really what "we" need?
>>
> 
> Yes, with flexibility.  Essentially every Linux box out there that's
> serving as a single-user workstation would benefit from this.
> It's a fairly basic usability issue for non-expert end-users.  We
> aren't dealing with hardware of ten years ago, where dynamic
> reconfiguration was only for extremely high end systems.
> 

> And if you look at this as an issue for larger systems, it's clear
> that "hot" reconfiguration is critical for preserving uptime; just
> think of hotplug events as configuration management alerts.


The issue is not whether dynamic, "hot", reconfiguration should be 
provided or not. That is already provided by the Linux kernel module 
paradigm and is basically identical to the way dynamic reconfiguration 
is handled in the "extreme high end systems" you're referring to.

The issue really boils down to whether a system-initiated 
reconfiguration event should be allowed to initiate administrator 
interaction.

Compare this to the package-provided configuration scripts used in 
various software packaging schemes. For many reasons, they cannot be 
allowed to do user interaction. Still, software installation under the 
windoze environment is very centered around package-provided user 
interaction, which, although "user-friendly", also _severely_ limits the 
flexibility of software installation.

So let's try to not confuse those things.

IMO, this is the simple and straightforward solution to provide what 
you're looking for:

  1) Any changes detected in the hardware configuration would fire a 
configuration script.

  2) That configuration script would do whatever is needed to introduce 
the device to the system, such as loading the corresponding kernel 
modules, and pick up and apply any default or persistant configuration, 
etc. All without any user interaction. This would run as root.

So far, this resembles the way things currently work in, for example, 
the PCMCIA subsystem. What follows is what you need to add...

  3) The introduction of a new device fires an event through some 
generic well-known framework.

  4) A user-level utility started by the administrator, which could be X 
based, would pick up the event and display the pop-up that would notify 
him of the configuration change and allow him to take appropriate action 
to (re-)configure the device, or in the case of a device that is not 
known to the system, allow him to install device support software.


The user level utility could be SUID root and do its own authentication 
(for example, checking if the user is the console owner) to allow a 
regular non-root user to run it. To avoid confusion about who should 
receive the configuration "alert", the event framework should probably 
only allow a single listener.

Ideally, the configuration changes themselves should occur through a 
generic interface so that the pop-up would not have to call any external 
procedures. There's a risk of crippling the flexibility of the user 
interface in that way, but it would remove the need for the device 
support software to provide any user-interface stuff. This would make it 
possible to change and enhance the user interface part without having to 
re-write any of the device support stuff, it will guarantee consistency 
in the user interface, and it would be much easier to avoid security 
problems. In this case, permissions could be handled by the generic 
configuration interface, and the user level utility would not have to be 
SUID root.

-- 
Christer Palm


_______________________________________________
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: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[Owen Taylor]

jg@pa.dec.com (Jim Gettys) writes:

> Owen:
> 
> This is certainly true: but not sufficient...

I wasn't trying to give a complete solution, just trying to dispell
any notion that interactivity with hotplug events would necessarily
involve popping up a root shell on the current login users desktop :-)
 
> Here's the sequence as I understand it:
> 
> 1) new device gets plugged in.
> 2) system has to figure out what driver to use.
> 3) if it has seen it before, presumably it can consult some sort of database
>    to help hook it up, both by whatever driver parameters it needs, and to hook
>    it up to a user level program it activates.  We're done at this point.
> 4) if the system has never seen it before, we have to somehow ask the user
>    what to do.
> 5) the driver finally gets loaded, with the user specified configuration
>    information that might be required.
> 6) record the necessary driver configuration, and go to 3).
> 
> So what we need is a convention whereby the hotplug framework activates
> a GUI component talking to the user somewhere on the network to get
> the configuration data required, and a way to communicate that configuration
> information back to the hotplug system to record for future use (and completion
> of the first hot plug event for that device).
> 
> So the hotplug scripts (running as root) have to be able to initiate the
> GUI talking to the user, and get data back from there.  And it isn't
> necessarily on the same system, as hotplug is not all about human interface
> devices: it is also used for disk drives, tapes, etc, and eventually pluggable
> processors, memory etc.
>
> So we have two problems:
>     o A convention of how to know who is administering this system.  It may
>     be this is something just for the hotplug folks to worry about.
>     o How to securely  get the right configuration back and forth from the user;
> this is the authentication problem, in concert with how to get data back
> and forth...

I think it probably makes sense to reduce the communication to one of
notification.

 - In response to the hotplug event, if the device can't
   be configured automatically, record that data, and
   notify the appropriate user(s).

 - When the user gets the notification, present them with the
   option to run a config tool, which would then complete
   the configuration.

This has various advantages; principally.

 - It's flexible (notification could be sending an email
   saying "go to this URL to configure your new printer.)

 - It reduces the authentication problem to a known and 
   solved problem. (Can user X do Y.)
   
In terms of how to do notification, you can go from simple to complex:

 - Watch a file in a timeout. (We had hotplug for USB storage
   devices in Red Hat 7.1 working quite nicely by watching
   /etc/fstab for changes; kudzu added new entries in 
   response to hotplug events. magicdev noticed the
   changes, signaled mc which added icons on the desktop.)

 - Local messaginge daemon; if you keep it simple, use unix
   perms, don't worry to much about quality-of-service, etc,
   it doesn't need to be a big project.

 - Networked based messaging; jabber, etc. May make
   sense to piggyback off an existing solution. But then
   you get the problem that you are talking about something
   big that everybody needs to adopt.

Anyways, just my random thoughts on the issue. My main observation is
that I think it's a mistake to think of this as "hotplug script pops
up a configuration dialog" even if it might appear like that to the
user in the simplest case.

Regards,
                                        Owen

 

_______________________________________________
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: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[Vladimir Dergachev]

On Mon, 4 Feb 2002, Jim Gettys wrote:

> 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, if the user is logged in so is the rest of the user interface. Why
not have a monitoring program (like console) that watches the hotplug
events and invokes corresponding configuration program ? This would also
allow for various user environments to customize configuration tools to
match their look.

                           Vladimir Dergachev

>
>
> --
> Jim Gettys
> Cambridge Research Laboratory
> Compaq Computer Corporation
> jg@pa.dec.com
>
> _______________________________________________
> Xpert mailing list
> Xpert@XFree86.Org
> http://XFree86.Org/mailman/listinfo/xpert
>


_______________________________________________
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: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[Oliver Neukum]

>
> Jim, if the user is logged in so is the rest of the user interface. Why
> not have a monitoring program (like console) that watches the hotplug
> events and invokes corresponding configuration program ? This would also
> allow for various user environments to customize configuration tools to
> match their look.

That solution is not in itself sufficient. You might not want everybody
to see all hotplug events.

	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: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[Christer Palm]

Oliver Neukum wrote:

>>Jim, if the user is logged in so is the rest of the user interface. Why
>>not have a monitoring program (like console) that watches the hotplug
>>events and invokes corresponding configuration program ? This would also
>>allow for various user environments to customize configuration tools to
>>match their look.
>>
> 
> That solution is not in itself sufficient. You might not want everybody
> to see all hotplug events.
> 


And what would the problem be with using an event distribution mechanism 
that would require the listener to have certain privileges?

-- 
Christer Palm


_______________________________________________
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: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[David Brownell]

> >>Jim, if the user is logged in so is the rest of the user interface. Why
> >>not have a monitoring program (like console) that watches the hotplug
> >>events and invokes corresponding configuration program ? 

Actually one of the goals of the hotplug framework is to avoid
requirements to have Yet Another Monitoring Daemon hanging
around wasting resources ... likewise, to avoid needing to start the
apropriate magic program before plugging in devices.
  

> >>This would also
> >>allow for various user environments to customize configuration tools to
> >>match their look.

... of course, if the events could get fed into some existing daemon
(via authenticared RPC, SSH-secured channel, or whatever) that
kind of appearance-agnostic behavior becomes simpler!   The issue
then becomes how hotplug identifes and accesses the channel, and
who will modify what existing daemons.  :)


> > That solution is not in itself sufficient. You might not want everybody
> > to see all hotplug events.
> 
> And what would the problem be with using an event distribution mechanism 
> that would require the listener to have certain privileges?

Another of the goals classic end-user "usability".  Remember that
the original problem was how to fire up an unprivileged tool ... not
all hotplug events imply any need for privilege. Users initiate hotplug
events with just physical access privileges.  When the device software
has already been set up, additional privilege shouldn't be needed.

- 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: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[Christer Palm]

David Brownell wrote:

> 
> Actually one of the goals of the hotplug framework is to avoid
> requirements to have Yet Another Monitoring Daemon hanging
> around wasting resources ... likewise, to avoid needing to start the
> apropriate magic program before plugging in devices.
>   


I wouldn't call using a few K's of memory a waste of resources. The 
program does of course not necessarily has to be started explicitly by 
the user. It would be added to whatever "autostart" mechanism the user 
interface in question would use.

>>>
>>And what would the problem be with using an event distribution mechanism 
>>that would require the listener to have certain privileges?
>>
> 
> Another of the goals classic end-user "usability".  Remember that
> the original problem was how to fire up an unprivileged tool ... not
> all hotplug events imply any need for privilege. Users initiate hotplug
> events with just physical access privileges.  When the device software
> has already been set up, additional privilege shouldn't be needed.
> 


Practically all desktop Linux distributions associates these kind of 
things with console ownership. If you're on the console, you are allowed 
access the graphics adapter, audio, floppy, cdrom, etc. devices. I don't 
see a problem with hotplug management following the same scheme. In fact 
, it _should_ follow the same scheme - wouldn't it be quite stupid if 
you could manage hot plug devices, but not access the floppy or cdrom?? 
Or does this concept have to change, too?


-- 
Christer Palm


_______________________________________________
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: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[David Brownell]

> > Actually one of the goals of the hotplug framework is to avoid
> > requirements to have Yet Another Monitoring Daemon hanging
> > around wasting resources ... likewise, to avoid needing to start the
> > apropriate magic program before plugging in devices.
> 
> I wouldn't call using a few K's of memory a waste of resources.

Most examples I've seen start at closer to an M or two, which
does matter.  I'd call such issues workable, though obesity in
GUI frameworks has sometimes reached criminal levels.


Re access rights:

> Practically all desktop Linux distributions associates these kind of 
> things with console ownership. If you're on the console, you are allowed 
> access the graphics adapter, audio, floppy, cdrom, etc. devices. I don't 
> see a problem with hotplug management following the same scheme.

Right, though it's not quite that simple even there.

The "single user desktop" model is well known to be the one
which is relatively straightforward to address -- and arguably hits
the "95% of end users" case here.  So long as one can kick in a
"no gui" mode for servers, and do something intelligent in the case
of multi-gui systems, that's a good place to start.

- 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: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[Vladimir Dergachev]

On Tue, 5 Feb 2002, Oliver Neukum wrote:

>
> >
> > Jim, if the user is logged in so is the rest of the user interface. Why
> > not have a monitoring program (like console) that watches the hotplug
> > events and invokes corresponding configuration program ? This would also
> > allow for various user environments to customize configuration tools to
> > match their look.
>
> That solution is not in itself sufficient. You might not want everybody
> to see all hotplug events.

I think it is. It is not very hard to to setup permission policy.. For
example you can only allow this to users who are able to login at the
console and not remotely. (By using GiveConsole/TakeConsole for
xdm/kdm/gdm for example).

I am sure you can get by with usual permissions based fifo in most if not
all situations. However it is not difficult to devise a way more generic
scheme than would ever be useful..

Say: have /var/hotplug/fifo/classX be fifos for different classes of
events. Have /sbin/hotplug filter incoming events and echo them into these
fifos. Have these fifos only accessible by root (or whatever /sbin/hotplug
runs under). Write a simple daemon that monitors classX fifos and also
/var/hotplug/fifo/command and passes the events onto a Unix socket on
localhost.. make it named if like :) /var/hotplug/events for example.

So, GiveConsole determines whether the user deserves access to classX
events and if yes echo something like this:
give_access classX 'xserver full displayname' A45GF_md5_random
into command fifo and sets "CLASSX_ACCESS_CODE" property on the root
window to A45GF_md5_random (with X being replaced by the class number).

The monitor app reads off these codes and passes them the daemon which
then uses them to actually enable passthru of messages.

When the server closes the root window gets destroyed and TakeConsole
echos the following:
revoke_access 'xserver full displayname'
to allow the daemon to discard codes that will no longer be used.

So, here, it was long and overcomplicated but I don't see how you may want
something more flexible than this.

                         Vladimir Dergachev

>
> 	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: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[Oliver Neukum]

On Tuesday 05 February 2002 02:22, Christer Palm wrote:
> Oliver Neukum wrote:
> >>Jim, if the user is logged in so is the rest of the user interface. Why
> >>not have a monitoring program (like console) that watches the hotplug
> >>events and invokes corresponding configuration program ? This would also
> >>allow for various user environments to customize configuration tools to
> >>match their look.
> >
> > That solution is not in itself sufficient. You might not want everybody
> > to see all hotplug events.
>
> And what would the problem be with using an event distribution mechanism
> that would require the listener to have certain privileges?

You may not want to base the distribution on privileges but on identity. eg
you want to associate some ports with some keyboards.
But in principle such a scheme should work.

	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: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[Dr Andrew C Aitchison]

On Mon, 4 Feb 2002, David Brownell wrote:

> The "single user desktop" model is well known to be the one
> which is relatively straightforward to address -- and arguably hits
> the "95% of end users" case here.  So long as one can kick in a
> "no gui" mode for servers, and do something intelligent in the case
> of multi-gui systems, that's a good place to start.

Not quite sure what you mean by "multi-gui systems".

Supplying a solution for "single user desktop" and "no gui servers"
will satisfy *almost* everyone.
However installing "single user desktop" on a classroom full of 
workstations runs the risk of being insufficently secure.
Although it may be a minority market, screwing it up could be very
bad for everyones reputation.

Even having a "classroom workstation" option, could be dangerous
if it doesn't have the features of "single user desktop", since some 
people will install the full-featured version however much you warn them 
of the pitfalls.
Besides it is much harder to bolt on security ofterwards.

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

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

[Oliver Neukum]

On Tuesday 05 February 2002 02:54, David Brownell wrote:
> > >>Jim, if the user is logged in so is the rest of the user interface. Why
> > >>not have a monitoring program (like console) that watches the hotplug
> > >>events and invokes corresponding configuration program ?
>
> Actually one of the goals of the hotplug framework is to avoid
> requirements to have Yet Another Monitoring Daemon hanging
> around wasting resources ... likewise, to avoid needing to start the
> apropriate magic program before plugging in devices.

You could have the demon started by inetd.

[..]
> > And what would the problem be with using an event distribution mechanism
> > that would require the listener to have certain privileges?
>
> Another of the goals classic end-user "usability".  Remember that
> the original problem was how to fire up an unprivileged tool ... not
> all hotplug events imply any need for privilege. Users initiate hotplug
> events with just physical access privileges.  When the device software
> has already been set up, additional privilege shouldn't be needed.

Not all users are equal in this regard. Eg. a FibreChannel network might
be quite extensive.

	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: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[Christer Palm]

Oliver Neukum wrote:

>>And what would the problem be with using an event distribution mechanism
>>that would require the listener to have certain privileges?
>>
> 
> You may not want to base the distribution on privileges but on identity. eg
> you want to associate some ports with some keyboards.
> But in principle such a scheme should work.
> 


Not only in principle, but also in practice, as I stated earlier. I 
would suggest having a look at "man pam_console", which is the way this 
kind of stuff is currently implemented.

There is no concept of more than one "local", i.e. console, user in 
Linux (or any other OS that I know of, for that matter), and changing 
that would be quite some work. Except for obscure vintage machines, does 
computers with more than one direct-attached keyboard even exist??

Anyway, in Linux, PAM is usually what (automatically) provides the 
mapping between session and privileges. You could add your own PAM 
module to associate the necessary privileges with a user session based 
on whatever parameters you want.


-- 
Christer Palm


_______________________________________________
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: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[Oliver.Neukum]

On Tue, 5 Feb 2002, Christer Palm wrote:

> Oliver Neukum wrote:
>
> >>And what would the problem be with using an event distribution mechanism
> >>that would require the listener to have certain privileges?
> >>
> >
> > You may not want to base the distribution on privileges but on identity. eg
> > you want to associate some ports with some keyboards.
> > But in principle such a scheme should work.
> >
>
>
> Not only in principle, but also in practice, as I stated earlier. I
> would suggest having a look at "man pam_console", which is the way this
> kind of stuff is currently implemented.
>
> There is no concept of more than one "local", i.e. console, user in
> Linux (or any other OS that I know of, for that matter), and changing
> that would be quite some work. Except for obscure vintage machines, does
> computers with more than one direct-attached keyboard even exist??

Support for more than one local user is a cornerstone of X and supported
in the kernel as well. In fact the X people are reportedly proud that
they've made it work.
Linux does support several graphics adapters, X supports the
machine:console.monitor notation and you can hook up dozens of
USB keyboards let alone terminals.

One local user is the typical case, but others must in principle work.

> Anyway, in Linux, PAM is usually what (automatically) provides the
> mapping between session and privileges. You could add your own PAM
> module to associate the necessary privileges with a user session based
> on whatever parameters you want.

You need filtering events as well. I don't want anybody to know
that I've plugged a webcam into the hub in my bedroom.

	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: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[Jim Gettys]

Please also understand that commercial Linux is succeeding in server 
systems.  Designing just for single user desktops is very short-sighted; 
commercially, much as I personally wish fervently otherwise, X desktops 
are not currently important.  But managing a server farm gracefully is 
commercially important.  And as I look into my tea leaves of the future, 
it looks to me we are moving toward a world (even at home), of random 
dedicated server boxes with remote displays.  And we are beginning to 
see deployment of Linux desktops in enterprises; again, remote configuration 
needs to be possible.

And people want to administer beowulf systems as though they were
one system, not N.

Again, the issue here for X to deal with is delegation of authorization
to connect to the user's X server.  Once we have that, various schemes
all work, and it will take a while to sort out the right policies on
the hotplug side of things, from what I can see of the discussion.

And yes, I want as little of this as possible: as much as possible, things
should plug in a work without human intervention.  But human intervention
needs to be possible.

More comments below.
                        - Jim
> Sender: linux-hotplug-devel-admin@lists.sourceforge.net
> From: <Oliver.Neukum@lrz.uni-muenchen.de>
> Date: Tue, 5 Feb 2002 12:35:41 +0100 (MET)
> To: Christer Palm <palm@nogui.se>
> Cc: <Oliver.Neukum@lrz.uni-muenchen.de>,
>         Vladimir Dergachev <volodya@mindspring.com>,
>         Jim Gettys <jg@pa.dec.com>, David Brownell <david-b@pacbell.net>,
>         Ryan Shaw <ryan.shaw@stanfordalumni.org>,
>         <linux-hotplug-devel@lists.sourceforge.net>, <wm-spec-list@gnome.org>,
>         <xpert@XFree86.Org>
> Subject: Re: [Xpert]Re: User-level Tasks in Hotplug Scripts?
> -----
> On Tue, 5 Feb 2002, Christer Palm wrote:
> 
> > Oliver Neukum wrote:
> >
> > >>And what would the problem be with using an event distribution mechanism
> > >>that would require the listener to have certain privileges?
> > >>
> > >
> > > You may not want to base the distribution on privileges but on identity.
> eg
> > > you want to associate some ports with some keyboards.
> > > But in principle such a scheme should work.
> > >
> >
> >
> > Not only in principle, but also in practice, as I stated earlier. I
> > would suggest having a look at "man pam_console", which is the way this
> > kind of stuff is currently implemented.
> >
> > There is no concept of more than one "local", i.e. console, user in
> > Linux (or any other OS that I know of, for that matter), and changing
> > that would be quite some work. Except for obscure vintage machines, does
> > computers with more than one direct-attached keyboard even exist??

Various people keep saying they want such things.  I'm personally somewhat
skeptical at this date, but making it hard/impossible seems wrong to me.

But on server systems, there are often many local users; they've logged
in, and are using the system.  Some may have full priviledges to the system.
Any of them, potentially, might be the operator of the system.

PAM looks interesting; it came along since the last time I groveled in 
the area...  Particularly if combined with Kerberos, it may provide a 
solution that meets the network transparency requirements (while not 
requiring kerberos in the simple single machine case).  But I'll have to 
do some homework.

> 
> Support for more than one local user is a cornerstone of X and supported
> in the kernel as well. In fact the X people are reportedly proud that
> they've made it work.

Yup.  Since 1984.  Not rocket science.  And many people use systems
without monitors on them.  People log into remote systems routinely, and
expect it to work, and they should be able to be notified even if
not on the local console.

> Linux does support several graphics adapters, X supports the
> machine:console.monitor notation and you can hook up dozens of
> USB keyboards let alone terminals.
> 
> One local user is the typical case, but others must in principle work.

Exactly.

> 
> > Anyway, in Linux, PAM is usually what (automatically) provides the
> > mapping between session and privileges. You could add your own PAM
> > module to associate the necessary privileges with a user session based
> > on whatever parameters you want.
> 
> You need filtering events as well. I don't want anybody to know
> that I've plugged a webcam into the hub in my bedroom.

Yup.  Certainly we do need filtration of some sort, somewhere.

                     - 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: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[Jim Carter]

Hmm, I seem to see a little different side of this issue.  In PCMCIA
hotplug, the user sticks in the card, and it says "beep-beep" if it loads
the driver and runs the init script, or "beep-blecch" otherwise.  That's
the extent of the GUI.  I think we should be starting from that end, not
the specific beeps, but with the idea of a very simple interface with
minimal user involvement.

When the card doesn't load, the person does "su root" (if privileged) and
starts mucking around with the card database, and even recompiling drivers
to add the PCI ID of the "you get what you pay for" rebrand card he (I)
bought. I'm not saying that some GUI help for the sysop is bad, but it's
going to be able to cover only limited and routine operations. I think the
main focus for the current discussion started out as a user-level issue,
starting a special init script that downloaded and displayed some photos,
not assistance for the sysop.

So one of our students in the lab plugs in his Rio or iPod into USB to copy
some songs to it.  If we have the drivers set up, fine, it works, no GUI
needed.  If we don't, you can be sure that we aren't going to offer him a
GUI so he can download nekulturny lyrics (that he probably didn't pay for)
in *our* lab.

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