linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: communicating with user login sessions
Date: Thu, 17 Apr 2003 23:50:14 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-105062897611681@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-104977671310586@msgid-missing>

Havoc Pennington wrote:
> Hi,
> 
> There's this text on the hotplug web site, not sure it's up to date:
> 
>    A gap in current Linux support is that policies with any sort of
>    dynamic "interact with user" component aren't currently
>    supported. For example, that's often needed the first time a
>    network adapter or printer is connected, and to determine
>    appropriate places to mount disk drives. It would seem that such
>    actions could be supported for any case where a responsible human
>    can be identified: single user workstations, or any system which is
>    remotely administered. This is a classic "remote sysadmin" problem,
>    where in this case hotplugging needs to deliver an event from one
>    security domain (operating system processes) to another (desktop
>    for logged-in user, or remote sysadmin), and any effective response
>    must go the other way. At this writing, Linux doesn't have widely
>    adopted solutions to such problems.

That particular text would still seem to be accurate ... :)

I think the main thing I'd say about that site is that it's
not been updated recently, or for 2.5 support.  I'd love a
volunteer who was interested in updating it, overhauling it,
or whatever.

I've added a link to D-Bus right there.


> This is by no means specific to device hotplugging - there's a general
> problem of delivering events from the OS out to user login sessions.
> Non-hotplug events might be things like "printer queue has changed"
> ...
>   http://www.freedesktop.org/software/dbus/

How would you speculate that a hotplug event should be delivered
to the "system message bus"?   I'm not quite sure how the kernel
would be expected to authenticate itself, or whether it should.
If there's going to be a daemon collecting kernel events, I tend
to think it should be able to read them directly ...

- Dave





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
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

  parent reply	other threads:[~2003-04-17 23:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-08  4:37 communicating with user login sessions Havoc Pennington
2003-04-08  5:20 ` Greg KH
2003-04-17 23:50 ` David Brownell [this message]
2003-04-18  0:13 ` David Brownell
2003-04-18  5:39 ` Havoc Pennington
2003-04-18  5:51 ` Havoc Pennington
2003-04-18 22:40 ` Greg KH
2003-04-18 23:45 ` David Brownell
2003-04-19  0:49 ` David Brownell
2003-04-19  1:24 ` Havoc Pennington
2003-04-19  1:30 ` Havoc Pennington
2003-04-19  1:43 ` Havoc Pennington

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-hotplug-105062897611681@msgid-missing \
    --to=david-b@pacbell.net \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).