Re: setpeuid(pid_t, uid_t) proposal

[Jerry Haltom]

> 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@xxxxxxxxxxxxxxx>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/