My custom Linux kernel

Status: obsolete; 2006-2007 (supersedes any conflicting remarks left on this page; see the home page for definitions)

Warning: Kernel matt5 seems to be hanging randomly; do not use it.  Furthermore, kernels up through matt5 do not restrict hardlinking others' files as claimed.  I am working on a kernel matt6 which will have both the hanging and the restriction fixed; I also plan to improve the coding style.  If you would like to adopt my custom kernel, I recommend that you wait for version matt6, although it might be a while in coming.

Addendum on 2007.08.05: Kernel matt6 is pretty much finished, but I haven't bothered to figure out how to release it.  Also, it will need to be updated to be based on the vanilla kernel 2.6.22.  If you want the kernel, email me and I will bother to release it.

Note on 2007-09-07: One major thing I would like to see on Linux is for the mounter of each filesystem to have superpowers on that filesystem, just as root has on the root filesystem.  (Mac OS X has "Ignore ownership on this volume", but superpowers for the mounting user would be even better.)  I might implement this in my kernel some time in the future.  Without this feature, it's difficult to use removable media containing an ownership-storing filesystem on multiple machines on which one has different uids without exposing the data to other users on those machines.

I customized my Linux kernel to enhance filesystem features.  It has additional behavior for the sticky bit, restrictions on hard linking (to tighten security), and on reiserfs, symlink permissions, lchmod, and lutimes.  You will find much more information in Documentation/filesystems/matt.txt of the custom kernel, which is available here as linux-matt3-doc-fs.txt.  (The documentation is unchanged in matt4.)

To get a copy of my custom kernel, apply a patch below to a Linux kernel of your choice.  Each patch is meant for a specific version of the vanilla kernel from kernel.org but is likely to work on other kernels.  Resolve rejected hunks if you dare.

My custom kernel has a "matt\d+" in its version number that gives the version of my customizations.  For example, kernel 2.6.16.13.matt1 is newer in general, but 2.6.15.1.matt2 has the newer set of my customizations.  I generally put a "kmatt\d+" (sometimes "matt\d+") in the name of customized software that works with a kernel having a specific version of my customizations.

Some of the customizations have to be done separately for each architecture (currently adding syscalls to unistd.h and the syscall table).  I made the customizations for i386 only.  If you use a different architecture, look at the i386-specific files the patch changes and make the corresponding changes for your architecture.

Note: The Linux kernel is copyrighted by Linus Torvalds and others and may be used only under version 2 of the GNU General Public License.  I waive all intellectual property interests of my own in the patches below, but since they contain pieces of the original kernel, it is my understanding that they are affected by the original copyrights.

Changelog for kernel customizations[# Top]

• matt1 (2006.01.18): Sticky bit restricts traversal.  You can't hardlink others' files into others' sticky directories.
• matt2 (2006.05.07): Symlink permissions, lchmod, lutimes work on reiserfs.  Writelink stub that gives ENOSYS.  You can only hardlink a file if you own it or could move it.
• matt3 (2006.05.13): lutimes allowed everywhere, symlink permissions only enforced on filesystems where they're settable.  You can move directories you can't write with rename(2).  Documentation improved.
• matt4 (2006.05.25): Fixed a bug that caused ELOOP when one opened through a symlink for writing.  Documentation is unchanged.
• matt5 (2006.08.26): Syscall numbers changed to 317 through 322 because 311 through 316 are now used in the official kernel.  Documentation is unchanged.  Hangy.

Customized glibc[# Top]

Here you have a customized version of Fedora Core 5's glibc that knows about my kernel's lchmod and lutimes and lets you call them by name in C programs.  If you install these packages and then configure rsync, it will use lchmod and lutimes to preserve symlink attributes.  Thanks to Mike Frysinger for helping me build them.  These "kmatt2" packages use the syscall numbers 311 through 316.

Like rsync-acl, these packages are named specially so automatic updaters won't replace them with ordinary packages, yet they have provide entries for the original package names.  Importantly, they also require each other instead of the original package names.  The upshot is that RPM-related tools will probably Do the Right Thing.

You may download the source RPMs and rebuild them on your computer with "rpmbuild --rebuild"; building takes two hours on my computer.  You must have my glibc-kernheaders installed before building my glibc.  If your computer's architecture is not i386, you will need to add the syscalls to that architecture's unistd.h in glibc-kernheaders; as far as I know, the glibc source package needs no changes.  Alternatively, if your computer's architecture is i386, you can use the binary packages.

Note: glibc is copyrighted by the Free Software Foundation and parts of it are copyrighted by others (see included LICENSES file).  I waive all intellectual property interests of my own in the customized glibc, but it is still available only subject to the LGPL and other licenses.

Customized qmail[# Top]

It's installed on my system, but I haven't distilled a patch to post yet.  If you want the patch, email me.

Customized coreutils[# Top]

Not written yet.  For now my system has three minimalistic utilities (lchmod, lutimes, writelink) whose source you will find below.  They use syscall(2) and syscall numbers 311 through 316, so they don't need the custom glibc; if your kernel uses syscall numbers other than mine, change the syscall numbers in the utilities' source.

Privileged deletion system[# Top]

Do you want to let users delete others' nonempty directories?  Set up a staging directory on each filesystem with a subdirectory for each user, named by UID (like /home/staging/500).  Then compile force-delete and empty-trash (customize them for your staging directories) and install them in /usr/bin.  Because my kernel lifts the restriction on moving directories one can't write, users can move an undesired directory to /path/to/staging/$UID/trash using force-delete.  Then they can call empty-trash, which is to be installed setuid-root, to recursively remove the directory.