Hi,
Patrice Dumas a écrit :
>On Fri, Sep 08, 2006 at 02:09:16AM -0300, Avi Alkalay wrote:
>
>
>>Well, these issues jumped to next releases.
>>
>>Also, to make the daemon really work with full permissions, I had to put a
>>setuid(0) call inside main(). And I changed the RPM spec so it now installs
>>kdbd as a +s program.
>>
>>
>That should never be needed, and when I say never, it is really never ;-).
>
>
I'm agree too. kdbd shouldn't have to be run as root. But actually its
needed because backends are storing some stuff into user's home
directory, and only root can achieve that.
We have to change this behaviour : no more store user settings into
their respective home directory but into a central place. For berkeleydb
that could give something like :
/etc/kdb-berkeley/system.db <= system/ namespace
/etc/kdb-berkeley/user:yl.db <= user:yl/ namespace
/etc/kdb-berkeley/user:foo.db <= user:foo/ namespace
... and so on
kdbd will then run as elektra.elektra and all these previously cited
file will be set to 640 and owned by elektra.elektra
Or perhaps simply a /etc/kdb-berkeley/elektra.db which will then store
everything (in my mind user shouldn't have to copy user:yl.db for backup
its user settings but rather have to use kdb -export. So splitting file
is somewhat useless)
>>I was thinking about the next steps for the daemon:
>>
>>- The libelektra-daemon.so should try to connect to a daemon. If it can't
>>find one, it should be started with exec() or system(). Thats why kdbd is
>>+s.
>>
>>
>
>I disagree with that design. A kdbd should be started by the super user
>(or equivalent) at boot, and not by a user at will. setuid programs bring
>too much security issues. There are allready much to be worried about since
>the daemon may be feed with incorrect data, so adding a setuid bit is
>really bad.
>
>
Yeah, i'm disagree too :-/ As i said yet, for me that smell like ugly
hack. I'd prefere a lot to allow namespace to backend mapping. Please
refere to a previous post :
http://article.gmane.org/gmane.comp.lib.elektra.devel/23
Backend mapping will allow init to use filesys backend (which is perfect
for low-level stuff) while still allowing other higher level software
benefit of the speed of daemon + berkeleydb.
Mapping will then allow to launch daemon a bit later in the boot process
using a standard init script.
>>- An eventual newly started daemon should open the listening socket. If it
>>already finds the file there (so it can't open it), it should test if there
>>is another daemon already running with some sort of ping, and there should
>>be some logic to decide when and how to kill a problematic daemon. Only one
>>kdbd should be running on the system.
>>
>>
Perhaps it will be better to put some effort to make this daemon never
problematic ;-) There are tools yet which monitor daemon and relaunch if
daemon is frozen (like "mon" if i remember correctly). I don't think we
have to implement such things into daemon itself.
Btw, it could be interesting to implement some timeout scheme into
daemon : killing connection unused for X minuts. Then libelektra-daemon
should be able to reconnect if needed. The problems i see is if daemon
"kill a connection" for timeout, that will send a SIGPIPE to client.
libelektra-daemon could catch it but what about if the client
application is using SIGPIPE for its own stuff yet ? I don't know a lot
about signal handling ...
>That's gonna be hard to be robust. The daemon should just be started
>in a classical init.d, drop the pid in /var/run such that it may be killed
>easily. But I think that apps should error out when the daemon is not
>started and not blindly launch another one, giving too much power to the
>user. And if the socket is allready taken it should also error out instead of
>trying to automatically solve an issue that cannot be automatically solved.
>Having a script or something like that which automates problem solving
>should be right, but doing that automatically from any app accessing
>configuration seems wrong to me.
>
>
So, i mainly agree with you but the part about "error out when the
daemon is not started". Since in my mind connection could simply die
(timeout) without reflecting a problem from kdbd. libelektra-daemon
should be able to "re-connect" automaticaly in this case. In short :
make kdbOpen() and "connectToDaemon()" different things (which is not
the case actually).
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
