Quoting Andrew Morgan ([EMAIL PROTECTED]):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andrew,
>
> The attached patch (171282b3553fcec43b9ab615eb7daf6c2b494a87) applies
> against 2.6.24-rc2-mm1. It addresses the problem reported by Kevin and
> Andy - ultimately, the legacy support wasn't transparent. In particular,
> userspace 32-bit capability manipulations (when run by root) that used
> to work, without this patch, fail.
>
> Cheers
>
> Andrew
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFHP8zBQheEq9QabfIRAs6/AJ9Tbn9vk/pgpu0FwOzU/EJg9oirjACaAndU
> unbe82Ep+s/y0Nl3aKP92uY=
> =8pOC
> -----END PGP SIGNATURE-----
> >From 171282b3553fcec43b9ab615eb7daf6c2b494a87 Mon Sep 17 00:00:00 2001
> From: Andrew G. Morgan <[EMAIL PROTECTED]>
> Date: Sat, 17 Nov 2007 21:03:19 -0800
> Subject: [PATCH] Legacy support fix; retain transparent support for 32-bit
> capability apps.
>
> Legacy support requires that we don't return an error for previously
> legitimate calls. Removing this check, we make a fail-safe best effort
> to support legacy applications.
Yeah, I struggled with this too.
This behavior makes particular sense if we think (as I do) that new
capabilities will mainly be introduced along with new features. So
legacy applications shouldn't misbehave due to ignorance or absence
(after capget+capset) of them.
> Signed-off-by: Andrew G. Morgan <[EMAIL PROTECTED]>
Acked-by: Serge Hallyn <[EMAIL PROTECTED]>
thanks,
-serge
> ---
> kernel/capability.c | 27 ++++++++++++++++++++-------
> 1 files changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/capability.c b/kernel/capability.c
> index 8cba9b2..9f2db55 100644
> --- a/kernel/capability.c
> +++ b/kernel/capability.c
> @@ -109,13 +109,26 @@ out:
> kdata[i].permitted = pP.cap[i];
> kdata[i].inheritable = pI.cap[i];
> }
> - while (i < _LINUX_CAPABILITY_U32S) {
> - if (pE.cap[i] || pP.cap[i] || pP.cap[i]) {
> - /* Cannot represent w/ legacy structure */
> - return -ERANGE;
> - }
> - i++;
> - }
> +
> + /*
> + * Note, in the case, tocopy < _LINUX_CAPABILITY_U32S,
> + * we silently drop the upper capabilities here. This
> + * has the effect of making older libcap
> + * implementations implicitly drop upper capability
> + * bits when they perform a: capget/modify/capset
> + * sequence.
> + *
> + * This behavior is considered fail-safe
> + * behavior. Upgrading the application to a newer
> + * version of libcap will enable access to the newer
> + * capabilities.
> + *
> + * An alternative would be to return an error here
> + * (-ERANGE), but that causes legacy applications to
> + * unexpectidly fail; the capget/modify/capset aborts
> + * before modification is attempted and the application
> + * fails.
> + */
>
> if (copy_to_user(dataptr, kdata, tocopy
> * sizeof(struct __user_cap_data_struct))) {
> --
> 1.5.1.3
>
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
