This is a 2.1 port of the capabilities patch for linux. 

There are some important enhancements in this version compared to the
2.0.31 version:

=== CHANGES in the 2.1.61 patch ===

  * updated to 2.1.61
  * all suser calls have been converted.
  * implemented ingo's idea for even faster capable().
  * did a number of changes to set*id be compatible with old programs. The
    semantics is as follows (note that we _don't_ clear the effective and 
    permitted sets in all cases as we agreed on. It's only correct
    in the setuid case).
     - When changing from uid 0 to some other uid with the possibility of 
       getting back, clear the effective bits.
     - When changing from some uid to uid 0, copy the effective bits from
       the permitted bits.
     - When changing from uid 0 to some other uid without the possibility
       of getting back (setuid/setresuid), clear the permitted _and_
       effective bits.
     - New securelevel-flag called SECURE_NO_SETUID_FIX disables this
       behaviour.
     - Note that changing fsuid isn't caught. 
     - Also note that this implementation means that all old programs that
       we wish to run in compatibility mode must run under uid 0. This
       means that all these programs will share DAC access to each other's
       files. This is a bit unfortunate IMO.
  * changes to the exec semantics to implement the semantics recently
    discussed. A new securelevel-flag called SECURE_NO_CAPFS_OVERRIDE
    disables this behaviour.
  * changes to exec in what is considered a "suid" exec. Now it's "suid" 
    if the permitted bits of the new process isn't a subset of the permitted
    bits on the current process.
    I still don't think the if (id_change) section in
    fs/exec.c:prepare_binprm is 100% correct.
  * SECURE_* constants changed. 
  * changing securelevel honors SECURE_FIXED and checks that we only
    set new _bits_ unless we're pid 1. (we were comparing the numerical
    values).

=== CHANGES in the 2.1.57 patch ===

  * when SECURE_LEVEL_DEFAULT is set to a bitmask containing
    SECURE_FIXED, issecure() will not check the 'securelevel' variable
    when one of the SECURE_LEVEL_DEFAULT-bits are checked.
  * capable() is reorganized and doesn't use _suser or _fsuser.
  * New system call numbers break everything ;-)
  * semantics change: SECURE_NOROOT is only checked when the kernel is
    compiled with POSIX6-support. This adds speed and makes sense.

As a result, capable() produces identical code to vanilla suser() when
compiled without POSIX6-support. Also, the POSIX6-version is just as fast
as the vanilla suser() (no more "POSIX6 is slow"). However, when POSIX6 is
used together with root-privileges it's 2-3 instructions slower
(load, test and branch on SECURE_NOROOT). 

=== CHANGES in 2.1.55 patch ===

Initial version.