Yannick Lecaillez wrote:
> José Luis Tallón wrote:
>
>> * map system/ to filesys directly
>>
>> * map system/sw to /var/lib/elektra/system-sw.db (640 elektra.elektra)
>> - or LDAP
>> - or MySQL
>>
>> * map user to either $HOME/.kdb/user.db
>> - or LDAP
>> - or MySQL
>>
> Yeah, the idea of multiple backend mapping is to allow you to map what
> you want to the backend of your choice.
Of course. I do understand this just like Bárður does: mappings are
"static" in the sense that modifying a "higher level"(i.e. closer to the
root) mapping requires elektra to be restarted.
> By the way, using kdbd + berkeleydb storing user:/ to their respective
> user's home directories
> will impose you to run this kdbd instance as root.
Not really... a separate process is forked for each user. It immediately
does a setuid() to become unprivileged.
> But this is why i
> defend idea of multiple backend mapping since the begining : that brings
> flexibility and you can do what you want. And that would not be complex
> as hell to implement.
>
Indeed
>> And the approach:
>> * filesys (direct) for init-like programs
>> * As soon as the daemon is running (libelektra checks if
>> /var/run/kdbd.sock is there), use the controller/slaves model which
>> Bárður has described before (a refinement of my original proposal). This
>> is the model used by many *high performance and secure* servers, such as
>> Apache and Postfix. Why not trust them for this? ;
>>
> Could you give more details please.
The architecture that I am proposing (and Bárður as well, only from a
slightly different perspective) is basically the same that both Apache
and Postfix follow: have a privileged "controller daemon" [basically
isolated from users] which spawns "unprivileged" processes to serve
requests (and also manages timeouts, etc)
NOTE: upon disconnection, "agents" would need to decide whether they
have serviced enough requests and have to terminate immediately or if
they can stay "idle" for a while -- awaiting further connections.
> Don't know if i uderstood you well
> ... you mean sort of "dynamic mapping" ?
Not at all. Mappings are to be kept in a central file --
"/etc/elektra/mappings.conf" is my suggestion.
BTW, this means having "re-entrant" backends: since a single shared
object can be used for different subtrees
> Use filesys for low level stuff directy. Then, when daemon is here, use it ?
> That mean a same
> configuration could be handled by two different backend depending
> wherever daemon is launched or not.
No, not really. It's only a matter of libelektra.so going via the socket
or loading the backend directly.
This is not done dinamically, but upon a request by the client program,
which must be running as root.
That is:
if( program requested direct access && getuid()==0 && socket not available )
{
load corresponding backend directly (possibly via an "adaptor" plugin)
execute requests directly
}
else
{
pass request to daemon
}
> I'm not really happy with this. Why not simply let mappings exactly like how
> they have been configured ?
>
That's what I'm saying.
The only difference is not using the daemon *when it can't possibly be
available*, that is at early stages of the system's boot sequence.
If the only process running is 'init', how could the daemon be used? the
logical approach for this is to allow libelektra.so to load the filesys
backend directly (potentially in R/O mode). This does introduce a minor
difference: some "essential" backends (such as "filesys" and possibly
"berkeleydb") will have to live under /lib/elektra, whereas the others
will be placed under /usr/lib/elektra/ --- the backends/ subdir here
seems redundant; there is no need to store kdbd's "components" anywhere
else, either.
>> Regarding security, the UNIX-domain connection method allows
>> libelektra.so the credentials of the calling process through the socket,
>> so that the user's permissions can be checked when accessing the
>> *shared* Berkeley-DB-backed configuration store.
>>
> This is how things are done yet, using SO_PASSCRED.
>
Didn't know it was already being done. It's a while since I last checked
the code :-|
>> One additional plus: the daemon (kdbd) can even *cache* the
>> filesys-backed configuration (which would be stored under
>> /etc/elektra/system/* ) into a BDB (or even memory!) a single inotify
>> handle would allow the daemon to invalidate/rebuild its cache upon
>> modification of filesys-backed config by the administrator (as opossed
>> to using kdb / kdbedit )
>>
> For me filesys don't have to be used with kdbd. More over, caching stuff
> under filesystem/ will probably not increase global performance a lot
> since stuff residing here aren't used oftenly (system/init,
> system/filesystems).
>
Keep in mind that you *need* to provide an NSS-eektra "bridge" (where
applicable) if this is to be actually used.
> The fact is i would have maximum flexibility and KISS (Keep It Simple,
> Stupid) as possible. Creating dynamicly pipe, process, agent will simply
> add complexity without adding (IMHO) enought good value.
>
I don't think we are speaking of pipes here (well, except for maybe some
synchronization between kdbd and the user's "agent")
> Adding caching stuff to kdbd is something i'm thinking too.
Let's simply make it possible and do the actual work for "version 2".
While we are at it, let's include some "ioctl-like" interface to request
some options from elektra: allow direct access, forbid caching, etc.
> Its "easy" to do for local backends (understand stored localy on filesystem)
> but
> not as easy for remote backends : cache system have to be aware about
> each modification done and these modifications could have be done not by
> you (your instance of kdbd). Afaik, LDAP allow you to monitor some
> branch/objectClass for modification. But for SQL that's another story ...
> So perhaps caching stuff would probably have to be done in the real
> backends themself rather than into kdbd.
>
Indeed. And for remote backends it normally does not make sense
J.L.
-------------------------------------------------------------------------
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
