PATCH: get unix user speed up

[Michael Krivoruchko]

Hi Robert,

On 18/10/05 14:08, Robert McQueen wrote:
> Michael Krivoruchko said:
>> Actually, I am working on per-uid message bus names. The idea is to let
>> a user to have private "channel" on the system wide bus. So the same
>> message bus name would represent different instances of a "service" for
>> different users. This would allow realtime data shearing between sessions
>> of the same user.
> 
> If you look a bit further back on the list archives, I was recently
> wondering about setting up a user bus type, with a per-user socket. This

Yes. I have seen this thread. ( I was the first one who replayed to you. ;)

> has possible security issues which concerned Havoc, and he didn't seem
> quite conviced there was a use case for this. 

Use case? All sorts of thin clients. We could start with XDMCP sessions
and go as far as SunRay (hardware thin client).

Well known name on the system bus would be right place to discover and
communicate with per-user daemon described by Havoc at the bottom of
this message:

   http://lists.freedesktop.org/archives/dbus/2005-September/003417.html

> This is a different solution
> for a similar problem, although I wonder if it's just overcomplicating
> things. What's your use case for this? Would it be sufficient to add a new
> bus configuration file which set up another uniquely-named (a-la-session
> bus) socket, and then registered the names with a user bus registry on the
> system bus (bus station? :D).
> 

If I understood you correctly, you suggest to start per-user instance
of D-Bus daemon. It should be fine unless you want to have a few hundreds
out of thousand LDAP or NIS users on the same machine. Per-user service
is almost zero configuration scenario, except the system bus configuration
should allow all (or some) users to own the name.

There is also per-user signals part. In addition to support per-user
services this would allow a system wide service to have per-user objects.
Method calls on these objects can be controlled by the service. I.e. service
can identify a calling user by the SENDER field of a message. However,
service cannot control signal emission on these objects. With appropriate
scheme for user identifier in optional DESTINATION field of the signal message
the bus could deliver the signal only to connections with matching user identifier.

Misha
--

On 25/9/05 02:27, Michael Krivoruchko wrote:
 > Hi Robert,
 >
 > I just wandering why it should be another bus? "Per-user bus" is
 > system wide bus, right? There is already system wide bus - the
 > system bus. User could start a service on the system bus. This
 > service can be as open to other users as it is necessary.
 > Alternatively a single system wide service can provide user specific
 > objects. In both cases the service can find uid of a client which
 > is trying to use an object exposed on the system bus by the service.
 > Thus, any attempt to invoke a method on a "per-user object" would
 > fail unless the client has matching uid.
 >
 > The system bus could provide "per-user namespace". Say, all objects
 > with path starting with '/<decimal_number>' are "per-user objects"
 > for a user with uid = decimal_number.
 >
 > The problem with "per-user objects" on the system bus is lack of
 > control over signals emitted by these objects. With current
 > implementation of the bus almost any client can receive signals
 > once it can connect. I believe, the bus could simply ignore attempts
 > to connect to a "per-user object" signals from clients with "wrong"
 > uid.
 >
 > Misha
 > --
 >
 > Robert McQueen wrote:
 >> Currently the specification for D-Bus outlines a system bus, which is
 >> per-machine, and a session bus, which is per-machine-per-user-per-login,
 >> and comes into existence when you log in, and goes away when you log out.
 >>
 >> I've got a few ideas of things which are currently (and some stuff I'm
 >> writing) being made to use the session bus which are actually not per
 >> session at all, and could well be better served by the addition of a
 >> third "user bus" (ie per-machine per-user) which can (but doesn't have
 >> to) persist between sessions. They can fall into one or both of two
 >> categories: those services which should not be duplicated if you log in
 >> multiple times, and those services which should be able to persist
 >> across logins.
 >>
 >> The former are things like evolution-data-server and gconfd, where your
 >> address book and preferences are clearly per-user and not per-session,
 >> so if you log in twice there's no good reason to spawn them again. The
 >> latter are things you don't want to go away between sessions, the
 >> example I'm thinking of being something like a connection to an IM
 >> server which could stay around and log your messages or forward them
 >> somewhere else, but you want your client to talk to it normally next
 >> time you log in.
 >>
 >> Its tempting to say that it might be desirable to refcount the session
 >> bus, have the new session "find" the existing session bus, and then
 >> terminate the session bus only when all sessions have logged out. I
 >> don't think this is the correct solution at all because it breaks the
 >> defined semantics (log in -> start, log out -> end) of the session bus,
 >> which are still useful in many cases despite the exceptions I've
 >> mentioned.
 >>
 >> Firstly, even though there are things as well as the per-machine
 >> per-user services I mentioned, there are definitely things that you do
 >> want to be session-specific - if you ask your browser to spawn a new
 >> window, you don't want it to find your browser in your other session and
 >> open one there. Secondly, doing a refcounted semi-persistent session bus
 >> also doesn't really provide a sensible way of persisting user-specific
 >> bus services on a given machine between logins.
 >>
 >> I think adding a third bus type of a user bus (more persistent than a
 >> session bus, but per-user unlike the system bus) would address both
 >> problems. It could be created when necessary, and represent itself with
 >> a unix socket on disk in a per-user determinable location (in per-user
 >> directories in /tmp or your home dir for example) protected by
 >> filesystem permissions. The daemon would stop when all the services went
 >> away - in some cases these could time out after no use as they currently
 >> do (eds, galago, gconf) or if they represent a persistent resource (IM
 >> connection) keep the user bus around while the resource exists.
 >>
 >> Comments? Should I write a spec (and maybe a dbus :D) patch?
 >>
 >> Regards,
 >> Rob
 >> _______________________________________________
 >> dbus mailing list
 >> dbus at lists.freedesktop.org
 >> http://lists.freedesktop.org/mailman/listinfo/dbus
 >
 >