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. > > 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. 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. 2) With a chroot, I couldn't mount /proc inside the namespace. It seems this might be a bug with 3.13? 3) I'm not sure how a chown should work (if at all) inside the namespace (eg: test/t4031-chown.sh) 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. Thanks, -Mike -- -- 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.
