Yannick Lecaillez wrote:
> (sorry for the big cut of the discussion, but that beginned a bit hard
> to snip it correctly ... :-p)
>
> Bárður Árantsson wrote:
>
>> I hope I'm not misunderstanding you, but the daemon cannot be run as the
>> user: It will not have the necessary access to system configuration
>> settings -- unless it happens to use the filesys backend which works by
>> virtue of the file system ACLs being identical with the Elektra ACLs.
>>
>>
> Daemon will be not runned as "the" user, but "as" user : Imagine a
> specific "elektra" special user (without shell). This user is then like
> "root" of configuration stuff. Not the system administrator, but the
> configuration administrator.
>
Ok, got it now.
> (but *not* to write settings into "real" users home directories)
I see this as a serious problem. (Because of the backup/multiple
machines issue.)
>
>> The backup issue is interesting though... If the user settings are to be
>> stored in the user's home directory then the daemon could spawn a
>> subprocess (which could setuid) for each user that is connected to it,
>> and direct all requests for user keys to the appropriate sub-process and
>> handle system keys itself.
>>
>>
> That's interesting but that seems a bit complex to implement : Have you
> got some idea how to implement "main" daemon to user specific daemon
> communication ? Memory sharing (mutex) ? Pipe (another layer to traverse
> : user application -> pipe -> main daemon -> pipe -> user specific
> daemon) ? Create pipe "on the fly" (user application -> main pipe ->
> main daemon (launching new kdbd process as user.user, creating a new
> pipe dedicated to this user) then user application -> dedicated pipe ->
> user specific daemon) ?
I was thinking of the last one (but see below...). Shared memory is
generally just a bad idea in general because it is too error-prone to
get the locking right. IIRC pipes are actually zero-copy on Linux, so no
extra copying overhead is incurred.
Thinking about it some more one could actually get away with using the
exact same program for both the user-specific daemon and the system daemon:
(Frontend)
Daemon
|
/ \
/ \
/ \
/ \
/ \
"/" (system) "user:"
daemon daemon
The frontend daemon (the one the user programs would actually
communicate with) would be a program running as root which could
spawn the "/" (system) daemon at startup (running as elektra:elektra),
and it could start "user:" daemons as necessary (running as the
particular user). Then the main job of the frontend daemon would be
to interpret the paths in requests and directing the requests to the
appropriate daemon.
(If one is willing to accept the possible security implications, these
actually don't really have be be separate processes, but they must not
be able to block each other's I/O).
>> I definitely think user settings should be stored in the user's home
>> directory. If the user wants to share settings across multiple machines
>> this is pretty much the only option.
>>
> You mean, as example, somebody who is exporting its home trought NFS to
> different machine (nis/yellowpage) ?
> That's a really good point.
Yes, or even just synchronizing through something like unison. If the
user configuration is stored somewhere other than the user's home
directory, a user would need a customized way to synchronize just for
elektra (using "-export"). If the user's configuration is stored in the
user's home directory, they can just synchronize the files directly
(Probably only makes sense with "filesys" backend, but I think it is
something worth considering.)
>
>> (There is technically another
>> option, namely only running a single daemon and letting the user specify
>> which daemon to use for user: settings. However, I think this
>> complicates matters even further by requiring the daemon to be
>> accessible over the network, etc.)
>>
>>
> That don't require daemon to be accessible over the network : map user:/
> to kdbd + a libelektra-mysql backend and let libmysql do the hard work
> (locking, networking, ...). That let you keep your settings centralized
> while using these at different place "at the same time" : PDA, Laptop,
> Home computer, Work computer ... Could be interesting.
... which would force you to run a full-blown RDBMS with all the added
complications of that. Administrative headaches aside, if your different
networks are far apart (latency-wise) your programs will slow to a crawl
with a centralized approach.
The only other system which I can think of right now which handles this
kind of thing reasonably well is LDAP. That might be *very* interesting
as a backend since it
a) natively supports replication to multiple sites (thus avoiding the
latency issue), and
b) is already hierarchical in nature, thus avoiding an awkward mapping
onto the relational model.
Of course setting up LDAP is a pain, but probably no less of a pain than
setting up MySQL. (And it would only be necessary in "enterprise"
scenarios).
It's been a long time since I looked at LDAP but IIRC it may even
support some fancy means of conflict resolution which is "sensitive" to
the hierarchical nature of the data.
>
> So i think there are good point about sharing settings trought home
> directory and there are good points too to sharing settings trought
> elektra ...
> Don't forget sharing settings trought home directory will always be
> possible using filesys backend directly without daemon.
>
>>> Hmm ... just got an idea .... Why not store system settings into
>>> /etc/<somewhere> (or /var/lib/<somewhere>) and user's specific into
>>> /home/elektra ? This way users keep their settings if they
>>> change/upgrade their distros and we don't have to run kdbd as root.
>>>
>> This doesn't really work with setups where users are spread out over
>> multiple physical volumes. For anything like that is is equivalent to
>> just storing the user keys in the same place as the system keys.
>>
>>
> That's right. But i think in a context of a single-computer "home
> usage", that still interesting.
> For users spread out over multiple physical volumes, that's a "real
> installation" and you could think about using libelektra-mysql or using
> libelektra-filesys directly.
Sure, it solves the immediate problem without addressing the larger
problem. The "store user config in $HOME" approach solves the problem
and also addresses the larger problem (though admittedly not fully).
--
Bardur Arantsson
<[EMAIL PROTECTED]>
Absolutely no one can sex a lobster without cutting it open.
rusty @ http://kuro5hin.org
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Registry-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/registry-list
