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>