Re: [fossil-users] Fossil in a chroot jail. Was: Chiselapp status
On Jul 13, 2018, at 8:58 PM, Warren Young wrote: > > On Jul 13, 2018, at 7:09 PM, Richard Hipp wrote: >> >> So, if you want to use the rate limiting feature on >> Linux, you will need /proc mounted in your chroot jail. I wish there >> were a better way… > > That’s actually one of the older features of cgroups. Maybe take a look? Reference: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/resource_management_guide/sec-cpu This isn’t quite the same thing as your current system, which cuts off service entirely when the load is high, but I think it’s more useful: allow a single process to use the whole CPU, but when there’s competition for the CPU, limit each one to a specific amount as needed to give each cgroup-controlled process a predetermined minimum slice. This part of cgroups was created specifically for the sorts of purpose you’re interested in: preventing one process from hogging the system when there are many non-cooperating processes running on the same hardware, as with multi-tenant VM hosting. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil in a chroot jail. Was: Chiselapp status
On Jul 13, 2018, at 7:09 PM, Richard Hipp wrote: > > So, if you want to use the rate limiting feature on > Linux, you will need /proc mounted in your chroot jail. I wish there > were a better way… That’s actually one of the older features of cgroups. Maybe take a look? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil in a chroot jail. Was: Chiselapp status
As a defense against DoS attacks, Fossil has a feature were it refuses to run certain expense web pages (ex: creating new tarballs) if the system load averages is too high. Fossil uses the getloadavg() interface to compute this. On Linux, getloadavg() requires that /proc be mounted. So, if you want to use the rate limiting feature on Linux, you will need /proc mounted in your chroot jail. I wish there were a better way... A Linux-specific hack here could be to open the `/proc/loadavg` file before entering the chroot and dropping privileges. You can then seek to zero and read as many times as you want. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fossil in a chroot jail. Was: Chiselapp status
On 7/13/18, Warren Young wrote: > > chroot() might even be strong enough given the tight scoping. Just checking to make sure you know: If you launch Fossil as root, it will automatically put itself into a chroot jail in the directory containing the repository, then change its userid and groupid to match the owner of the repository. It does this prior to reading any content from the wire. The chroot jail that Fossil runs in can be very lean. It does not need a shell nor a bunch of libraries (assuming you have statically linked). You will need to mknod a /dev/null, /dev/random, and /dev/urandom inside the jail, but that seems harmless enough. As a defense against DoS attacks, Fossil has a feature were it refuses to run certain expense web pages (ex: creating new tarballs) if the system load averages is too high. Fossil uses the getloadavg() interface to compute this. On Linux, getloadavg() requires that /proc be mounted. So, if you want to use the rate limiting feature on Linux, you will need /proc mounted in your chroot jail. I wish there were a better way... -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
