Patrice Dumas wrote: >It could run as root, but not setuid. In fact I think that the normal >use case would be to launch the daemon as root, do the initialization >things that requires root rights (if any) then drop privileges by >becoming elektra.elektra > 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)
>and regain root privileges only when needed, >that is when accessing a file (or a db) which is not readable/writable >by the elektra.elektra user. > > My idea is to make all these files or db r/w to elektra user. This way, kdbd could run all the time as elektra.elektra and we're sure kdbd will "never " permits users to gain root. But sure, if someone suceed to become elektra.elektra its stil catastrophic : it will be able to read/write all the configuration ... I don't really know but i think change privilege is probably an heavy task for kernel which could kill performance. Moreover, perhaps race condition could occur and allow to gain root privilege. >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 ? >For berkeleydb, yes, but for filesys it may be more simple and hopefully >not less secure to regain and redrop privileges only for the file open >and close. Indeed if things are in the user HOME, it could be less >easy for a malicious user to steal things or the like. > > You're totally right. But i didn't thought about filesys : it haven't got to be run trought kdbd, its have its own privilege separation layer yet (the filesystem/kernel). Another point why kdbd shouldn't be run as root : try kdb system/../../ using filesys backend. Sure its a known bug and this will be corrected, but perhaps there are other bugs we didn't show yet. >Agreed. Moreover config required by initscripts should be robust, >simple and easy to repair, binary db aren't good at that. > > Yes that's the idea : don't prevent a good booting process. As soon you succeed to gain a shell (and have backup :-)) you can repair everything. Btw, i think berkeleyedb is a quite strong database (OpenLDAP database is using berkeleydb as default for persistence layer). But for have benefit of this reliable aspect, we'll probably have to add some transactional and locking mechanism into libelektra-berkeleydb. 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
