Messages in this thread | | | Subject | Re: setpeuid(pid_t, uid_t) proposal | From | Jerry Haltom <> | Date | Tue, 24 Aug 2004 01:27:50 -0500 |
| |
> What does this buy you that having the separate daemon just do > a fork/seteuid/exec to do the work, and passing the results back via a > Unix socket or shared mem or what-have-you?
To do a seteuid the daemon would need to be root. This means it would be processing remote information of a sensitive nature, such as Kerberos ticket acquisition, SASL stuff, etc, as root. Something I'm trying to avoid. It has to first determine what uid before it can call setuid and the process of determining this uid is very sensitive in many situations.
> Alternatively, what would this give you that isn't already done by > the SELinux support for cron, or Apache suexec, which already allow > "run the following in another context" functionality?
I don't know about this SELinux thing you speak of yet, I'll look into it. Apache suexec spawns a seperate process for each individual request. It cannot function properly with in process modules, such as mod_webdav, mod_php, and... all the others. Being able to function in process is the main idea behind this.
Jerry Haltom <wasabi@larvalstage.net>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |