GitLab

While most people (especially who use tmpfs as top writable branch)
doesn't care, I care and think it can be a security problem.
For example, when the lower readonly branch may contain
/etc/{passwd,shadow} and the permission bits of the upper empty
branch is world-writable, then a malicious user can make these files
manually with by-passing aufs.
Aufs can do nothing but produce a warning.

For details, see aufs manual in aufs-util.git.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

This commits brings a list of the inode numbers which indicates the
logically renamed dir into a branch. The list will be referred in
lookup, and its lifetime is equivalent to the branch's, ie. the list is
loaded/created in adding a branch, and stored/deleted in deleting a
branch. The simple storing happens in remounting and unmounting aufs
too.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

The permissions and attributes of a branch can be modified dynamically.
See also the document in this commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Implement the user interface.
Since users often wonder "Why I cannot delete this branch?", 'verbose'
option was introduced.

You may think aufs should not hold several strings for the variation of
the option, and the mount helper (/sbin/mount.aufs) can convert all
variations to a single fixed string, and in kernel space aufs should
contain this only one string.
I agree, but in our real world, many users don't install
/sbin/mount.aufs. To be convenient, aufs contains these variations.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Delete a branch which is not busy.
Aufs judges the branch is deletable by testing the opened files, the
cached dentries and inodes. Even if a directory is in use, as long as
the same named entry exist on another branch, then the branch is
deletable.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Maintain the internal array including corresponding XINO file and sysfs
entries.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

In order to prevent firing the notify event from aufs itself, hnotify
feature is suspend/resume-able. They are combined with mutex lock/unlock
for the parent dir.

See also previous commits.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

As a result of branch management, the virtual inode may point a
different real inode from it used to. And aufs has to maintain its
address_space_operations, since its definition may affect the
behaviour.
I know some people (including grsec-patch) doesn't like a non-const
address_space_operations, but in order to keep the consistency of the
behaviour, the correct address_space_operations is important.

See also the document in this commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

The internal file read/write for copy-up in kernelspace.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Copy the inode attributes between branches.
See also the document in this commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Actually prepare the whiteout bases on the adding writable branch.
For details, refer to previous commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

The branch path can be much longer and it is not suitable to print via
/proc/mounts as a part of mount options. Aufs can show it either
separately via sysfs or /proc/mounts (as a part of mount options).
This approach affects the lifetime of aufs objects and sbinfo contains
kobject (in another commit). Theoretically user can disable
CONFIG_SYSFS, but the lifetime management is always necessary. So
supporting sysfs is split into two files, sysaufs.c and sysfs.c.
sysaufs.c is always compiled, but sysfs.c is compiled only when
CONFIG_SYSFS is enabled.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

XINO and XIB files are read and written frequently after unlinked, and
it means that the remote filesystems are not suitable for them.
Additionally aufs shows their metadata via debugfs (in later commit).
To make it easier to do this, aufs expects branch filesystems to
maintain their i_size and i_blocks. And it means some filesystem are not
suitable for XINO.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

For details, see previous commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

The branch object is managed by the sbinfo object as an element of its
internal array. The iinfo and dinfo objects contain the branch id, and
it will be used to implement the correct order in branch management
(add/del).

See also the documents in this commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>