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/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:18 EST