(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.
Imagine a kdbd running as elektra.elektra and storing system
configuration into /etc/kdb-berkeleydb/<here>.db where :
/etc/ is (at least on my system) 755 root.root
/etc/kdb-berkeleydb 750 elektra.elektra
/etc/kdb-berkeleydb/<here>.db 640 elektra.elektra
kdbd runing as elektra.elektra will be allowed to read/write into
<here>.db file and so, read/write system wide settings.
(but *not* to write settings into "real" users home directories)
>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) ? Or perhaps i've misunderstood you ?
>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.
> (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.
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.
Regards,
Yannick.
-------------------------------------------------------------------------
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
