> I've been playing with the namespaces support in uwsgi latelly, and I've
> found several issues:
>
> - first of all, the for(;;) endless loop for starting a namespace is too
> aggressive. If there's any error in the namespaced child, it'll take
> 100% of a cpu. Some kind of backoff would be required here (although
> that comes close to an implementation of an init system)
The only thing coming to my mind is having a sleeping system (similar to
anti-fork-bombing in the master) where the more errors appear the more
sleep time will be used. Other ideas ?
>
> - the second problem is that uwsgi first unmounts all the mount points,
> and if the wanted ns root is on a separate filesystem (say /home) it'll
> get unmounted, before it's bind mounted on ns_tmp_mountpoint.
> (a chdir(uwsgi.ns) before unmount all, helps)
this will leave the original /home mounted in the jail or am i missing
something ? (no problem here, i have already thought about a system to let
some mountpoint available in the jail)
>
> - if you ask me, I'd name the 2 .uwsgi_ns_tmp_mountpoint directories
> differently, to avoid confusion (see next issue). Maybe
> .uwsgi_ns_newroot_mountpoint and .uwsgi_ns_putold_mountpoint
ok
>
> - rmdir("/.uwsgi_ns_tmp_mountpoint/.uwsgi_ns_tmp_mountpoint"); can not
> succeed from the namespaced child, since it's already rooted inside the
> first .uwsgi_ns_tmp_mountpoint
this is not very clear to me, i will make some check but a error in such
case should be reported.
>
> - since uwsgi is started from some other filesystem/mount point, that
> mount point will not be unmounted, so the child will keep a reference to
> the master namespace allowing it to exploit it (although there are some
> precautions against that, still). One thing that's possible is a *read
> only* bind mount of the uwsgi executable inside the child root, and
> re-execing the child from there.
wow, i did not know that MS_BIND could be applied to file too. This is
very useful.
>
> - the namespacing part never fails, afaik it should fail at least if
> pivot_root doesn't succeed, and maybe also on
> umount("/.uwsgi_ns_tmp_mountpoint") if the above issue is solved
>
right, i will fix this
>
>
> ps.
> uwsgi_start is a HUGE function, pressing % on the begining brace in vim
> to find the ending doesn't even work. I'd suggest breaking it in several
> smaller functions.
>
You are right (again), for now i will move out the namespace part for
sure, after the official release i will start cleaning uwsgi.c
--
Roberto De Ioris
http://unbit.it
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi