Re: CAP_SYSLOG, 2.6.38 and user space

From: david
Date: Sat Feb 05 2011 - 02:06:23 EST


On Fri, 4 Feb 2011, Serge E. Hallyn wrote:

Quoting Gergely Nagy (algernon@xxxxxxxxxx):
On Fri, 2011-02-04 at 16:05 +0000, Serge E. Hallyn wrote:
Quoting Serge E. Hallyn (serge@xxxxxxxxxx):
From 2d7408541dd3a6e19a4265b028233789be6a40f4 Mon Sep 17 00:00:00 2001
From: Serge Hallyn <serge@peq.(none)>

At 2.6.39 or 2.6.40, let's add a sysctl which defaults to 0. When
0, refuse if cap_sys_admin, if 1, then allow. This will allow
users to acknowledge (permanently, if they must, using /etc/sysctl.conf)
that they've seen the syslog message about cap_sys_admin being
deprecated for syslog.

Signed-off-by: Serge Hallyn <serge@xxxxxxxxxx>
- goto warn; /* switch to return -EPERM after 2.6.39 */
+ !capable(CAP_SYSLOG)) {
+ /* remove after 2.6.39 */
+ if (capable(CAP_SYS_ADMIN))
+ WARN_ONCE(1, "Attempt to access syslog with CAP_SYS_ADMIN "
+ "but no CAP_SYSLOG (deprecated).\n");
+ else
+ return -EPERM;
+ }
}

why does this need to be removed after 2.6.39?

whenever you go to remove it you will break userspace, what's the benifit of breaking userspace?

I can understand that it's better to have a syslog daemon with CAP_SYSLOG instead of CAP_SYS_ADMIN, but does "it would be better to have userspace changed" really translate into "it's so important to have userspace changed that we need to break any userspace that hasn't changed"?

I really don't think so.

David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/