![]() | |||||||||||||
Messages in this thread Patch in this message |
Andy Lutomirski <luto@myrealbox.com> writes:
> + /* Pretend we have VFS capabilities */
> + cap_set_full(bprm->cap_inheritable);
> + if ((bprm->secflags & BINPRM_SEC_SETUID) && bprm->e_uid == 0)
> + cap_set_full(bprm->cap_permitted);
> + else
> + cap_clear(bprm->cap_permitted);
I'd move this to security/commoncap.c:
diff -urN a/fs/exec.c b/fs/exec.c
--- a/fs/exec.c Fri May 14 10:07:28 2004
+++ b/fs/exec.c Fri May 14 12:07:18 2004
@@ -912,13 +912,6 @@
}
}
- /* Pretend we have VFS capabilities */
- cap_set_full(bprm->cap_inheritable);
- if ((bprm->secflags & BINPRM_SEC_SETUID) && bprm->e_uid == 0)
- cap_set_full(bprm->cap_permitted);
- else
- cap_clear(bprm->cap_permitted);
-
/* fill in binprm security blob */
retval = security_bprm_set(bprm);
if (retval)
diff -urN a/security/commoncap.c b/security/commoncap.c
--- a/security/commoncap.c Fri May 14 10:07:28 2004
+++ b/security/commoncap.c Fri May 14 12:08:30 2004
@@ -107,8 +107,16 @@
int cap_bprm_set_security (struct linux_binprm *bprm)
{
- if (newcaps)
+ if (newcaps) {
+ /* Pretend we have VFS capabilities */
+ cap_set_full(bprm->cap_inheritable);
+ if ((bprm->secflags & BINPRM_SEC_SETUID) && bprm->e_uid == 0)
+ cap_set_full(bprm->cap_permitted);
+ else
+ cap_clear(bprm->cap_permitted);
+
return 0;
+ }
/* Copied from fs/exec.c:prepare_binprm. */
> + /* FIXME: Is this overly harsh on setgid? */
> + if ((bprm->secflags & (BINPRM_SEC_SETUID | BINPRM_SEC_SETGID)) &&
> + new_pI != CAP_FULL_SET)
> + bprm->secflags |= BINPRM_SEC_NOELEVATE;
> +
> + if (bprm->secflags & BINPRM_SEC_NOELEVATE) {
> + is_setuid = is_setgid = 0;
> + cap_clear(fP);
> + }
This prevents sendmail from being setuid mail and
cap_net_bind_service=ep.
Regards, Olaf.
-
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/
| ||||||||||||
| Last update: 2005-03-22 13:03 [from the cache] ©2003-2008 | |||||||||||||