Patrice Dumas wrote: > On Sat, Sep 09, 2006 at 04:37:25PM +0200, Yannick Lecaillez wrote: > >> Patrice Dumas wrote: >> >> Yeah, you're right. root privilege will be required for create the kdbd >> socket to a more conventional place than the current one (/tmp/elektra.sock) >> > > Not necessarily. If, say, /var/elektra is owned by elektra.elektra, the > socket could be opened there. Would be much better that in /tmp where > there is furthermore a possible symlink attack. > This was for a "fully-owned, launched-by-the-user" agent. As it is right now, I would use the same socket as the "main" daemon --- in fact, we are using the "front-end / multiplexer daemon" which we have discussed earlier. The socket in question is /var/run/kdbd.sock 666 root.root
By using a UNIX-domain socket + SO_PASSCRED we can verify the identity of any process connecting to the daemon. Moreover, there is only one socket per user process. Keep in mind that this "user configuration daemon" would need to have a connection (another UNIX socket), I guess) to the "system daemon". This is so that proper ACL checks can be performed. Moreover, mappings can only change upon a "user configuration daemon" dying. That means incorporating a retry mechanism within libelektra.so My .02€ > > [snip] > If this is owned by the user, then indeed it requires a carefull > design since it is required to be able to become root at some point, > to be able to change uid to the user uid, and the process must also > be able to talk to each other. Not easy. > In fact, it becomes easier this way: a "central" daemon which only receives and accepts connections, forks the corresponding "configuration agent" daemon [ which then does a setuid(user) thus dropping privileges ] and a *single* instance of a "global configuration daemon" running as elektra.elektra and reading/writing config under /etc/elektra/ [filesys] and /var/lib/elektra [berkeleydb] >>> It even seems to me that it would make sense to >>> drop privileges even when called directly from libelektra, say in the >>> filesys backend. >>> >>> >>> >> Sorry, i didn't get your point. Could you give some more details please ? >> > > No, this was a mistake of mine. In fact filesys cannot be easily used from > within the kdbd process since it would invlolve changing uid from within > the filesys code which seems wrong. > It can indeed, when loaded from within an unprivileged "user configuration daemon". The only point left to solve here is an efficient way of communicating these unprivileged daemons with their "master". However, using (1+n) sockets per logged in user which is making use of elektra [ 'n' being the number of independent processes/process groups run by that user] doesn't seem to be that much. 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
