Hi, I'm trying to use Apache for a file service, with multiple processes. I want to get user file permissions from the OS itself, by setfsuid-ing every time of the individual daemon process (yes, I know that there are other - perhaps better - ways to achieve this. but this is what I need). I'm using the mod_wsgi module, and a python script. I'm setting up several daemon processes for serving the requests, when Apache is originally executed from a root-process that has SETUID and SETGID capabilities, in all its capabilities sets (I set them in the INHERITABLE set, and verified). The daemon (non-root) processes run under "daemon" user (uid = 2). However when I look at /proc/<some httpd pid>/status >I see that the capabilites are only passed to the initial "httpd" process, and all the others have them set only in their INHERITABLE set. i.e. initial process has CapInh: 00000000000000c0 CapPrm: 00000000fffffeff CapEff: 00000000fffffeff while the others have CapInh: 00000000000000c0 CapPrm: 0000000000000000 CapEff: 0000000000000000 And as expected setfsuid() has no effect. To rule out mod_wsgi as the source of the problem, I deleted the check that forbids it from being used with root user, re-installed, and indeed I can then setfsuid() as I wish. So it seems to me the problem does not lie there, but somewhere in the way httpd creates the new processes and the capabilities are passed on. Admittedly I'm no kernel expert, and this is my first experience with the capabilities feature. So I'd appreciate any help and useful idea to what I do wrong. Some tecnical details: httpd 2.2.14 OS - RHEL 5.34 (kernel 2.6.18) mod_wsgi 3.1 Python 2.5.4 Thank you, Osi --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|