All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.