VS Context Quota Concepts

How Context Quota Support works ...

The basic idea came from the VS developer/maintainer Jacques Gélinas.
He wrote on his introductory pages (chapter 6.2.1 Per context disk quota) ...

The kernel has already user and group disk quota. Adding security
context disk quota should be easily done.

To differentiate between user IDs in virtual servers, the kernel could
coin together the security context and the user id to create a unique ID.
The kernel 2.4 now supports 32 user ID, so combining security
context and user ID in a single 32 bits number should be acceptable.

My first idea (and suggestion) was to implement a mapping of

  • X = (C << N) ^ (U & ((1 << N)-1))
  • U = X & ((1 << N)-1)

where X is the 32bit ID written/read to/from disc, C the current context,
N the number of bits reserved for uids, and U the local uid.

While this is basically correct and somewhat sufficient, a simple mapping
(like this) is unable to satisfy some, more difficile aspects of real world
per context/user quotas like

  • Unification across context boundaries
  • Physical server backup/restore

Therefor I decided to extend this concept, and take a more general approach,
by making the inode structure context aware (this was already done by
Jacques for the devpts filesystem). (This is neither necessary nor seems to
be the best approach, but at least it is an approach ;-)

The current release (vquota-0.10) does the following, primitive mapping at
the filesystem level (specifically between raw_inodes and inodes)

  • Uraw = (U & 0xFFFF) | (C << 16)
  • Graw = (G & 0xFFFF) | (C << 16)
     
  • U = Uraw & 0xFFFF
  • G = Graw & 0xFFFF
  • C = Uraw >> 16

Having context information available with each inode, it seems logical to
extend the access controls to check for context too. Currently all inode access
restrictions I found, where extended to check for the context, with a special
rule active for files of context 0/1 (physical/info context). Files of context
0 are handled as if they belong to the current context, which should permit
unification without additional changes. If such a file is modified, it silently
migrates to the currently active context.

The stat and chown system call were modified to handle the security contexts
0 (physical) and 1 (info) specially, by for stat report the "raw" values for
uid and gid and for chown accepting 32bit uid/ctx combinations.


00166 visits to this page.
©2002 Herbert Pötzl