Quoting Christian Seiler (christ...@iwakd.de): > Hi, > > I've attached three additional patches for possible improvements to > lxc-attach. > > The first two I think should be applied directly, they do the > following: > > 1) Create a sane fallback to /bin/sh if it is impossible to detect > the container's shell because of incompatible nss implementations > between host and container > > 2) Detect the user & group id of PID 1 and use that for lxc-attach > instead of root, when attaching to user namespaces. > > The third patch I'm not really sure about the security implications of, > so I'm sending it as a draft, but somebody who knows more about the > specifics should look over it. > > 3) Add -u and -g options to lxc-attach to allow the user to specify > user and group ids to setuid()/setgid() to when attaching. > > This feature could be really useful, on the other hand, I have > only ever used lxc running as root (never tried lxc-setcap), so I > have no idea if this could pose a potential security problem or > not. (When running as root, you have all the rights anyway, so > then it's fine.) I'd like some feedback on this before I feel > comfortable signing off on adding these options. > > Now if somebody tells me that attach is only possible as root > anyway so far, then I don't have any qualms, but I'd rather be > safe than sorry.
It *should* be safe. You can only attach to namespaces to which you have CAP_SYS_ADMIN, and in there you can only setuid to uids which are valid in that namespace. That said, it's not impossible that there would be subtle implications I've not considered. Let's see what others think. -serge ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
