Hi Mike, On Sat, Jul 26, 2014 at 5:29 AM, Mike Shal <[email protected]> wrote: > > On Wed, Jul 9, 2014 at 9:43 PM, Paul Colomiets <[email protected]> wrote: >> >> Hi, >> >> Two weeks ago I've posted an issue about using tup in linux containers: >> >> https://github.com/gittup/tup/issues/184 >> >> Issue should be trivial to fix, but I've not received any answer. > > > Sorry for the delay - things have been quite busy for me :(. > > I think this should be fixed now. I just removed the #ifdef that had a > similar hack for OSX, so now if getpgid() fails, we just ignore the check. > > The issue with limiting things to the same pgid is due to the dependency > detection. If other processes were to access the FUSE fs, they might > incorrectly add file accesses to sub-processes. That might just be overkill > though, since the @tupjob markers aren't visible in the top-level file > listing. > > In any case, please report any further issues you have with it. I did seem > to have some strange and inconsistent failures when running the tests in a > container, but I'm not sure what the cause is. >
Thanks a lot! I've moved off the tup on the project because of the issue. But I hope I can try it again soon. >> >> >> Also with the recent linux kernel its actually possible to run tup >> chroot as a non-root user without tup being setuid binary (google for >> user namespaces). I understand that tup runs not only on many >> platforms, but it would be nice if this feature is supported on linux. >> >> Should I make a pull requests on both issues? >> > > Have you worked with namespace containers before? I had some limited success > when a tried a while ago, since it required a kernel config change to enable > it then, I didn't continue with the implementation. > Yes. Currently it's enabled by default in ubuntu 14.04 (and seems to be in recent centos and debian too). But not in Archlinux yet :( > I tried again recently, and I had a few issues: > > 1) I couldn't mount the FUSE fs in the child namespace. Probably not too big > of a deal, but it means the parent process needs to access everything > through the anchor fd before mounting the FUSE fs over top of either '/' or > the root of the tup hierarchy. > >From quick testing it seems fuse need a setuid binary, and setuid binaries usually do not work in user namespaces. I'm not familiar with internals of fuse, so I don't know if it can be avoided. But you can create fuse filesystem before creating namespace. It's perfectly ok to add bind mounts on top of fuse-backed FS. (remember to bind recurisive, as kernel prevents non recursive bind mounts, if there is another mount point inside; it seems as a security measure). Not sure I understand why you need anchor fd. In case you need to access both fuse filesystem and underlying filesystem you may bindmount old root somewhere inside your new namespace. (However using anchor fd may be not a bad idea too). > 2) With a chroot, I couldn't mount /proc inside the namespace. It seems this > might be a bug with 3.13? >a There are two options mounting /proc: 1. Make a PID namespace along with user and mount namespaces 2. bind mount /proc in namespace (bind mount must be recursive) Kernel doesn't allow to mount new /proc of same pid namespace as a security measure > 3) I'm not sure how a chown should work (if at all) inside the namespace > (eg: test/t4031-chown.sh) > For real file systems it works. As long as you are root inside a namespace and the source and target users are mapped. I'm not sure how it works with fuse. > It's definitely something that should be supported in the future, certainly > for getting rid of the annoying .tup/mnt paths that show up in some > sub-processes, as well as not having to make tup suid. Hopefully we'll get > there soon. I agree with Ben that until it's widespread, we should still > support the suid way for older kernels. > Sure. Looking forward to see it implemented :) -- Paul -- -- tup-users mailing list email: [email protected] unsubscribe: [email protected] options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
