Date: Sun, 25 Aug 2013 00:17:34 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Valeri Galtsev <galtsev@kicp.uchicago.edu> Cc: freebsd-jail@freebsd.org Subject: Re: per user quotas inside jail? Message-ID: <20130824211734.GT4972@kib.kiev.ua> In-Reply-To: <55726.68.255.103.36.1377376501.squirrel@cosmo.uchicago.edu> References: <19176.128.135.70.2.1377267872.squirrel@cosmo.uchicago.edu> <20130823160549.GD4972@kib.kiev.ua> <17536.128.135.70.2.1377281124.squirrel@cosmo.uchicago.edu> <20130823182356.GH4972@kib.kiev.ua> <37112.128.135.70.2.1377283759.squirrel@cosmo.uchicago.edu> <20130824150831.GO4972@kib.kiev.ua> <55726.68.255.103.36.1377376501.squirrel@cosmo.uchicago.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--/uRvsyw+hu2Bjn8E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 24, 2013 at 03:35:01PM -0500, Valeri Galtsev wrote: >=20 > On Sat, August 24, 2013 10:08 am, Konstantin Belousov wrote: > > > > I decided that I have no desire to try to understand all the layers of > > indirections which are only relevant to you anyway. Instead, I demostr= ate > > you what I mean by working quotas. Below is the transcript of the simp= le > > test. > > > > sandy% mount -v /mnt > > ~ > > mount: /dev/ada1p4: Operation not permitted > > /dev/ada1p4 on /mnt (ufs, local, with quotas, soft-updates, writes: syn= c 2 > > async 37, reads: sync 7 async 0) > > sandy% sudo repquota -uah | grep kostik > > ~ > > kostik -- 14G 0 0 - 461057 > > 0 0 - > > sandy% sudo jail -u kostik / test1 127.0.0.1 /bin/sh > > ~ > > $ dd if=3D/dev/zero bs=3D1m of=3D/mnt/1/dddd count=3D1024 > > 1024+0 records in > > 1024+0 records out > > 1073741824 bytes transferred in 10.765265 secs (99741328 bytes/sec) > > $ ^D% > > sandy% sudo repquota -uah | grep kostik > > ~ > > kostik -- 15G 0 0 - 461058 > > 0 0 - > > > > You could see that the accounted space and inodes are properly increased > > after the dd. > > > > IMO, you should make sure that the users operate on the filesystem which > > has quotas enabled. Or, you should provide a simple to reproduce test > > case, among the lines of the script I pasted above, for me to recreate > > the issue locally. > > >=20 > Thanks again for helping me! I guess, I understand now what the difference > is. Apparently, you are much better expert, so correct me if I'm wrong. >=20 > You run your jail with root of jail filesystems (/) the same as root > filesystem of host (/). Therefore, inside your jail you have access to all > host's /etc/fstab; /dev, ... I'll try to run jail the same way and will > see if in that case quotas will work for me. If yes, then I at least I > will know that my problem is not on the kernel level, but in the > environment accessible inside jail. After the quotas are configured and running, it is purely kernel-side code which handles the limits and accounting. You do not need usermode access to fstab or quota files. The same experiment as was done above, but now I copied /bin/dd and ld-elf.so+libc.so into jail root, to convince you that access to the full host environment does not matter: sandy% ls -la /mnt/1/fsx = ~ -rw-r--r-- 1 kostik kostik 1032128299 Dec 21 2012 /mnt/1/fsx sandy% sudo repquota -uah | grep kostik = ~ kostik -- 15G 0 0 - 461064 = 0 0 - sandy% sudo jail -u kostik /mnt/1 test1 127.0.0.1 ./dd if=3Dfsx of=3Dxsf bs= =3D1m ~ 984+1 records in 984+1 records out 1032128299 bytes transferred in 10.262390 secs (100573871 bytes/sec) sandy% sudo repquota -uah | grep kostik = ~ kostik -- 16G 0 0 - 461065 = 0 0 - >=20 > I have all jails set up so that one when in jail is not able to access > filesystem outside jail's own root, which is something like > /jail/{$jailname}... therefore host's /etc /dev are not visible for one > inside jail; what they see inside jail as / is /jail/{$jailname} on host. Let me repeat, verify that the actions which are supposed to be limited by quotas happen on the filesystem which has quotas configured. Or provide me with the minimal example in style I posted so that I can reproduce the issue locally (I very much doubt that this is the case, and not a misconfiguration). --/uRvsyw+hu2Bjn8E Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSGSLtAAoJEJDCuSvBvK1BQscP/A+HKG8x4gtxXWtpdlyh+NNI Y5DrnDI74NN1hfCDitKPbhRd7zaoUHR0wS6YuBqobUOspQjMxeshNQwFB/ssBxLb oaVqxZcebL68DGxWXFyNpBxQVTIdgXoAGmIVkJxWA30lcCrJykFRKxfYZkEs7YxY WDruk90fDV8s6XaCft1Buh40c5bULkQMvoCsdzyt3vTeaS7BtzQiK9IPuo4gBlgJ qdKGY3ThtUBgabX/P148Abka7/bQc6WWnlz8NzQlVF7gkTCc7Yt/KMAzCFgOTwHC 8EKQ0oqWxqKKlOZYC0UjnZRhKIAKgdiEWv/LvdatJlEM9uEdlQE4u/D4CR7qrbY5 VawSnXCBLoDYWBlCddmpufdA9cKxCGzWwVkS+ThC1DoVO8Q67LVNIGJfYTJ+Ol4Y sDLF0D0aSbG7FTJW4cS65xFxMyOoMwzR4CkcslI/oi+CiN7YtkFOKqBh06cBee6F 4zwt/sjuTpZDWPoNugz21b3HKkRnd3fucoRg8Sa+2563I1UkbhvrXwVPJ0uH8Kdg xVp0gnUOsYrdvrFUTdd8fhpehyaAwelVJdp0zVYDKvVjPgi51QEMtsu7SMkqG0D4 aVHkWWDNy1g9bDLnweiZnl16Q/a9k4q448Mn9IbQ2cAOcsfvEFE6SnxQM3WEv7XM bHO2rfZuNPLEWoDkuVkD =urvw -----END PGP SIGNATURE----- --/uRvsyw+hu2Bjn8E--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130824211734.GT4972>