From: "Dmitry Yu. Bolkhovityanov" <D.Yu.Bolkhovityanov@inp.nsk.su>
To: linux-hotplug@vger.kernel.org
Subject: Re: User-level Tasks in Hotplug Scripts?
Date: Mon, 04 Feb 2002 06:02:32 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-101280328232394@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-101256895903801@msgid-missing>
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
next prev parent reply other threads:[~2002-02-04 6:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-01 13:09 User-level Tasks in Hotplug Scripts? Ryan Shaw
2002-02-01 23:58 ` David Brownell
2002-02-02 20:55 ` Jim Gettys
2002-02-02 22:02 ` Oliver Neukum
2002-02-02 22:12 ` Jim Gettys
2002-02-02 22:52 ` Oliver Neukum
2002-02-02 23:02 ` David Brownell
2002-02-03 0:58 ` Scott Cuyle Fritzinger
2002-02-03 8:36 ` Greg KH
2002-02-04 6:02 ` Dmitry Yu. Bolkhovityanov [this message]
2002-02-04 15:10 ` Jim Gettys
2002-02-04 19:28 ` Jim Carter
2002-02-05 3:32 ` David Brownell
2002-02-05 15:05 ` Ryan Shaw
2002-02-06 14:30 ` Marcus Harnisch
2002-02-06 14:54 ` Jim Gettys
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-101280328232394@msgid-missing \
--to=d.yu.bolkhovityanov@inp.nsk.su \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.