Messages in this thread | | | Date | Sat, 13 Mar 2010 23:35:21 -0600 | From | "Serge E. Hallyn" <> | Subject | Re: [PATCH] Define CAP_SYSLOG |
| |
Quoting Michael Kerrisk (mtk.manpages@googlemail.com): > > There is one downside to this patch: If some site or distro currently > > has syslogd/whatever running as a non-root user with cap_sys_admin+pe, > > then it will need to be changed to run with cap_syslog+pe. I don't > > know if there are such sites, or if that concern means we should take > > a different approach to introducing this change, or simply refuse this > > change. > > *If* this is a problem, would the way to address it not be to permit > syslog if the caller has *either* CAP_SYS_ADMIN or CAP_SYSLOG? (The > only weakness I see in this idea is that it fails to lighten the > hugely overlaoded CAP_SYS_ADMIN.)
Which becomes a very big weakness because it won't allow a container to be started with cap_sys_admin but not cap_syslog in its capability bounding set.
So, if it is deemed a problem, then the alternative will be to introduce a syslog namespace. Container setup can then create a new syslog namespace, and can no longer read or clear the host's syslog.
thanks, -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |