I am running 2.2.14 with VLAN and IPsec patches.
I have patched capability.h to give init cap_setpcap along with
everything else, and modified fs/exec.c like this:
========================================
--- exec.c.orig Wed Oct 27 00:53:42 1999
+++ exec.c Tue Apr 11 17:05:12 2000
@@ -623,12 +623,8 @@
* smart").
*/
- if (!issecure(SECURE_NOROOT)) {
- if (bprm->e_uid == 0 || current->uid == 0)
- cap_set_full(bprm->cap_inheritable);
- if (bprm->e_uid == 0)
- cap_set_full(bprm->cap_effective);
- }
+ cap_set_full(bprm->cap_inheritable);
+ cap_set_full(bprm->cap_effective);
/* Only if pP' is _not_ a subset of pP, do we consider there
* has been a capability related "change of capability". In
========================================
My goal was to let non-root processes *begin* with particular
capabilities by using a wrapper (e.g. sucap) to gain capabilities
then execve() the desired program.
On reboot, I found my user shell running with =eip , which
kernel/sys.c:cap_emulate_setxuid() should prevent (when setiud()
is called upon login)
A test program that prints caps before and after a setuid() (from root
to user) shows that "=eip" is changed to "=i", as it should be. If
the setuid() is from user to himself, caps are unchanged - good.
But 'su' does NOT drop capabilities like I expected:
bash-2.03# su snikt -c 'getpcaps $$'
Capabilities for `11792': =eip
I can't find the significant difference between 'su' and my test
program yet. I'm still tinkering with it.
Is this a bug?
Eric Buddington
snikt@resounding.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:16 EST