Documentation/filesystems/aufs/design/04branch.txt

   1
   2 # Copyright (C) 2005-2011 Junjiro R. Okajima
   3 #
   4 # This program is free software; you can redistribute it and/or modify
   5 # it under the terms of the GNU General Public License as published by
   6 # the Free Software Foundation; either version 2 of the License, or
   7 # (at your option) any later version.
   8 #
   9 # This program is distributed in the hope that it will be useful,
  10 # but WITHOUT ANY WARRANTY; without even the implied warranty of
  11 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  12 # GNU General Public License for more details.
  13 #
  14 # You should have received a copy of the GNU General Public License
  15 # along with this program; if not, write to the Free Software
  16 # Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
  17
  18 Branch Manipulation
  19
  20 Since aufs supports dynamic branch manipulation, ie. add/remove a branch
  21 and changing its permission/attribute, there are a lot of works to do.
  22
  23
  24 Add a Branch
  25 ----------------------------------------------------------------------
  26 o Confirm the adding dir exists outside of aufs, including loopback
  27   mount.
  28 - and other various attributes...
  29 o Initialize the xino file and whiteout bases if necessary.
  30   See struct.txt.
  31
  32 o Check the owner/group/mode of the directory
  33   When the owner/group/mode of the adding directory differs from the
  34   existing branch, aufs issues a warning because it may impose a
  35   security risk.
  36   For example, when a upper writable branch has a world writable empty
  37   top directory, a malicious user can create any files on the writable
  38   branch directly, like copy-up and modify manually. If something like
  39   /etc/{passwd,shadow} exists on the lower readonly branch but the upper
  40   writable branch, and the writable branch is world-writable, then a
  41   malicious guy may create /etc/passwd on the writable branch directly
  42   and the infected file will be valid in aufs.
  43   I am afraid it can be a security issue, but nothing to do except
  44   producing a warning.
  45
  46
  47 Delete a Branch
  48 ----------------------------------------------------------------------
  49 o Confirm the deleting branch is not busy
  50   To be general, there is one merit to adopt "remount" interface to
  51   manipulate branches. It is to discard caches. At deleting a branch,
  52   aufs checks the still cached (and connected) dentries and inodes. If
  53   there are any, then they are all in-use. An inode without its
  54   corresponding dentry can be alive alone (for example, inotify/fsnotify case).
  55
  56   For the cached one, aufs checks whether the same named entry exists on
  57   other branches.
  58   If the cached one is a directory, because aufs provides a merged view
  59   to users, as long as one dir is left on any branch aufs can show the
  60   dir to users. In this case, the branch can be removed from aufs.
  61   Otherwise aufs rejects deleting the branch.
  62
  63   If any file on the deleting branch is opened by aufs, then aufs
  64   rejects deleting.
  65
  66
  67 Modify the Permission of a Branch
  68 ----------------------------------------------------------------------
  69 o Re-initialize or remove the xino file and whiteout bases if necessary.
  70   See struct.txt.
  71
  72 o rw --> ro: Confirm the modifying branch is not busy
  73   Aufs rejects the request if any of these conditions are true.
  74   - a file on the branch is mmap-ed.
  75   - a regular file on the branch is opened for write and there is no
  76     same named entry on the upper branch.