On Sun, Sep 10, 2006 at 06:15:29PM +0200, José Luis Tallón wrote:
> >
> 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
It could also be /var/run/elektra/kdbd.sock 666 elektra.elektra
with /var/run/elektra/ 755 elektra.elektra
> 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.
Not necessarily. A possibility would be that there is no proper
'user configuration daemon' but process which communicates through
anonymous pipe with the main daemon... as you describe below.
> 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]
Agreed. It is also what I have in mind.
> > 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".
Yep, but the scenario I had in mind was different, lets forget about
what I said before.
> 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.
It seems to me that 2 pipes could be opened between the main daemon
and a 'user configuration agent' which could be persistent (and even
pre-launched). Every process needing to access a key would make a
connection to use UNIX socket.
A drawing could be:
|---------| |----------------| |-----------------|
| program | get/set a key | kdbd dispatcher| <-----> | system |
| linked | <----------------> | run as elektra | pipe | configuration |
| against | | but launched | | agent (elektra) |
| elektra | UNIX socket | as root | |------+----------|
|---------| |+-----------+---| :
: /|\ : get/set
: | : key in
+-------------+ +------+ \:/ /var or
: pipe | ' /etc
: | backend
\:/ \|/
' '
when accessing |-----------|
user: keys, create pipe | user |
regain root fork/setuid | config |
rights, only ===============> | agent |
to setuid | (user id) |
user config |-----------|
agent :
: get/set key
\:/ in user home
'
backend
The fork/setuid cost shouldn't be too much problematic since they should
happen only once for each user and not for every connection. The
dispatcher could also fork a another process to handle the communication
with agents, or not, or use threads, but that's an implementation detail.
The agents should stay there as long as possible in my opinion.
--
Pat
-------------------------------------------------------------------------
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
