Messages in this thread Patch in this message | | | Date | Thu, 10 Feb 2000 20:13:42 +0000 (GMT) | From | Matthew Kirkwood <> | Subject | Re: Capabilities |
| |
On Thu, 10 Feb 2000, Chris Evans wrote:
> > I don't believe that this is functionality for its own sake. If > > you think or it as a sysctl which allows you to turn off bits of > > SECURE_NO_SETUID_FIXUP. > > It _is_ functionality for its own sake, because the design of the > capabilities system gives you the tools you need.
But the implementation doesn't.
This is the same argument which we heard against a capability bounding set, and I consider it thoroughly bogus in both cases.
> We will have filesystem support soon.
I see no evidence of that. The last patch I saw (admittedly, I haven't been looking hard for one) was against 2.1.xx, and used reserved space in the ext2 inode which has since been used for other things. Linux has available a pair of __u32s in the on-disk inode which is not sufficient, I believe[0]. reiserfs has no inode space reserved for future expansion.
I am not saying that these are good things but merely that I can't see filesystem-format inducing changes arriving in a great hurry for so little direct gain.
> Once you have that, the solution becomes one of userspace setup rather > than kernel support. Complexity is better in userspace than the > kernel.
Don't claim that this is complexity. A(n untested) patch to implement it is appended to this email. It really is that easy.
> We don't want to introduce temporary kernel tweaks between now and > such time as we have filesystem support for capabilities, because then > people will _use_ that support and we could get stuck with it.
The all-powerful-root legacy is so great that the additional hassle of rooting out problems caused by this change are far, far outweighed by its usefulness, IMHO.
Matthew.
[0] My thinking is somewhat slow today, but as I recall the fs caps implementation wants to include all three sets, yes?
--- linux-2.3/include/linux/capability.h.capsetuid Thu Feb 10 19:55:06 2000 +++ linux-2.3/include/linux/capability.h Thu Feb 10 19:55:36 2000 @@ -276,6 +276,11 @@ extern kernel_cap_t cap_bset; /* + * Privs that setuid-root programs get + */ +extern kernel_cap_t cap_setuidset; + +/* * Internal kernel functions only */ --- linux-2.3/include/linux/sysctl.h.capsetuid Thu Feb 10 19:56:33 2000 +++ linux-2.3/include/linux/sysctl.h Thu Feb 10 19:57:50 2000 @@ -110,7 +110,8 @@ KERN_SPARC_STOP_A=44, /* int: Sparc Stop-A enable */ KERN_SHMMNI=45, /* int: shm array identifiers */ KERN_OVERFLOWUID=46, /* int: overflow UID */ - KERN_OVERFLOWGID=47 /* int: overflow GID */ + KERN_OVERFLOWGID=47, /* int: overflow GID */ + KERN_CAP_SETUIDSET=48 /* int: capabilities given to suid-root programs */ }; --- linux-2.3/kernel/sys.c.capsetuid Thu Feb 10 19:52:21 2000 +++ linux-2.3/kernel/sys.c Thu Feb 10 20:06:04 2000 @@ -350,7 +350,8 @@ cap_clear(current->cap_effective); } if (old_euid != 0 && current->euid == 0) { - current->cap_effective = current->cap_permitted; + current->cap_effective = cap_intersect(current->cap_permitted, + cap_setuidset); } } --- linux-2.3/kernel/sysctl.c.capsetuid Thu Feb 10 19:52:39 2000 +++ linux-2.3/kernel/sysctl.c Thu Feb 10 19:59:37 2000 @@ -253,6 +253,8 @@ {KERN_OVERFLOWGID, "overflowgid", &overflowgid, sizeof(int), 0644, NULL, &proc_dointvec_minmax, &sysctl_intvec, NULL, &minolduid, &maxolduid}, + {KERN_CAP_SETUIDSET, "cap-setuidset", &cap_setuidset, sizeof(kernel_cap_t), + 0600, NULL, &proc_dointvec}, {0} }; --- linux-2.3/kernel/capability.c.capsetuid Thu Feb 10 20:00:44 2000 +++ linux-2.3/kernel/capability.c Thu Feb 10 20:00:35 2000 @@ -17,7 +17,7 @@ * uninteresting and/or not to be changed. */ -kernel_cap_t cap_bset = CAP_FULL_SET; +kernel_cap_t cap_bset = CAP_FULL_SET, cap_setuidset = CAP_FULL_SET; asmlinkage long sys_capget(cap_user_header_t header, cap_user_data_t dataptr) {
- 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/
| |