Tom Evans wrote:
On Tue, 2009-05-26 at 17:01 +0400, Menshikov Konstantin wrote:
Kostik Belousov wrote:
On Tue, May 26, 2009 at 04:35:04PM +0400, Menshikov Konstantin wrote:
Kostik Belousov wrote:
On Tue, May 26, 2009 at 10:32:24AM +0400, Menshikov Konstantin wrote:
In structure prison it is added structures containing disk quotas and
usage.
At start Jail, we calculate the size root path and number of files in
it, thus receiving current use of a disk.
In functions of allocation of disk blocks and inode, we check quotas and
we increase current use.
UFS cannot determine whether the new allocation goes under the jail
root or not.
Yes. But jail cannot allocate block and inode above root path. In
allocation functions, whether for example ffs_alloc we have access to
ucred process and we can check up there is a process in jail.
Yes, you can check this for jailed process. Think about non-jailed processes
that can do allocation below the jail root.
Processes out of jail are not considered.
I do not understand, these processes have what relation to disk to
quotas for jail. Please explain more in detail
A process outside of the jail can still write to the file system that
you consider to be jailed, depending upon permissions. If all your quota
calculations are only triggered by jailed processes writing to the file
system, then you can exceed quota trivially.
Tom
The primary goal of disk quotas to limit allocation of disk blocks and
inode to processes in jail during their work.
Jail it is time essence. After end of work Jail, it does not exist.
Let's consider disk quotas for Jail, as number of blocks or inode which
jail can use during a session.
I understand that if process out of jail will create in a root directory
jail a file of the sizes in 1 GB, and process in jail will remove this
file jail can exceed the limit on 1 GB.
But there is no real necessity, in an operating time jail to write down
in the root catalogue jail from the outside jail.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
