Avi Alkalay wrote:
> Well, these issues jumped to next releases.
>
> Yannick, about the bug we were trying to solve this morning, I fixed it
> inside BDB. It was a problem regarding key contextualization
> (userDomain) when running under the daemon (another user). I just didn't
> understand how it was working for you.
>
> I also changed the way the daemon backend identifies itself. A 'kdb
> info' now shows 'daemon+berkeleydb' instead of 'daemon+ddefault'.
>
> 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.
>
> 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.
Having to use +s is always a Bad Sign(TM). There are basically two choices:
a) Using a setuid binary + talking to the user application through a
socket/pipe.
b) Using a regular binary started by root + talking to the user
application through a socket.
Both require extreme care when accepting input from the user
application, but in alternative a) one must *additionally* also be
extremely careful about scrubbing the environment, setting umasks,
always using absolute paths, etc.
In short: Choice a) is more difficult to get right and AFAICS has no
significant advantages over approach b). (Also see below).
> - 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.
This is a hack. As others have already said: The proper way to do this
is to have the root user start the daemon from
rc.d/init.d/daemontools/svc/runit/etc. This allows completely trivial
and robust monitoring without needing any hacks. (Incidentally, the
daemon should also have an option to avoid backgrounding -- it is
important for 'init' replacements which actively monitor daemons).
This also prevents all the race conditions that might occur with a
"user-started" daemon.
> - So I think at least a ping mechanism with timeouts should exist
> between client and server, and server and server.
There is no need for this with a "root"-started daemon.
Cheers,
--
Bardur Arantsson
<[EMAIL PROTECTED]>
Linus isn't just a good C programmer. After half a decade of
watching him catch stuff like this in just his public LKML
messages, I'm convinced he would have seen this if he were
reading braille hardcopy of it from across the room while drunk.
Tailhook @ http://slashdot.org
-------------------------------------------------------------------------
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
