Integrated David Hedberg's GSoC proposal

Needs more work but the formatting is reasonable.
He gave his permission on IRC.

2 files changed, 770 insertions, 0 deletions

diff --git a/community/gsoc/project_ideas/libcap.mdwn b/community/gsoc/project_ideas/libcap.mdwn
index 875b462f..1346203d 100644
--- a/community/gsoc/project_ideas/libcap.mdwn
+++ b/community/gsoc/project_ideas/libcap.mdwn
@@ -31,6 +31,10 @@ Some knowledge of POSIX capabilities will need to be obtained, and for the
 latter part also some knowledge about the Hurd architecture. This project is
 probably doable without previous experience with either, though.
 
+David Hedberg applied for this project in 2010,
+and though he didn't go through with it,
+he fleshed out many [[libcap/details]].
+
 Possible mentors: Samuel Thibault (youpi)
 
 Exercise: Make libcap compile on Debian GNU/Hurd. It doesn't need to actually
diff --git a/community/gsoc/project_ideas/libcap/details.mdwn b/community/gsoc/project_ideas/libcap/details.mdwn
new file mode 100644
index 00000000..aa27a84e
--- /dev/null
+++ b/community/gsoc/project_ideas/libcap/details.mdwn
@@ -0,0 +1,766 @@
+[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled
+[[GNU Free Documentation License|/fdl]]."]]"""]]
+
+[[!meta title="Details on implementing libcap"]]
+
+
+This is the proposal submitted by David Hedberg for GSoC 2010 (who opted
+to go with another mentoring organization), adapted from an initial
+proposal and several amendments into a single document, but the idea
+is to further adapt it to a more neutral design document over time.
+
+
+# The proposal
+
+### Quick description of POSIX capabilities
+
+The original suggestion can be found [[here|libcap]].
+POSIX capabilities never actually entered the POSIX standard but was
+left as a draft.  Linux has nevertheless implemented this draft, and
+there are reasons for doing the same in the Hurd - a more fine grained
+control of rights leading to increased security being one of them.
+
+POSIX capabilities are give on a per-process basis, and basically allows
+splitting up those rights usually granted to root into smaller and more
+specific rights.  Examples of capabilities are CAP_CHOWN and CAP_KILL,
+overriding certain restrictions on chown and allowing the process to
+kill processes with different UID's, respectively.
+
+Each process is given three sets with capabilities: the Permitted set
+(P), the Effective set (E) and the Inheritable set (I).  The effective
+set contains the capabilities that are currently active.  The permitted
+set contains the capabilities that the process has the right to use.
+The inheritable set contains the capabilities that can be inherited
+by children to the process.  A process can drop capabilities from its
+permitted set, but not set them.  The effective set and the inheritable
+set can be changed freely as long as they stay subsets of the permitted
+set.
+
+Capabilities can also be set on executables.  When executed, the resulting
+process is given the capabilities both as defined by the parent process
+and by the capabilities set on the file (formula below), resulting in
+what might be explained as a fine-grained setuid.  Implementing this
+requires support for *xattr* or similar.
+
+Some applications that are currently using capabilities are samba, ntp,
+vsftp, pure-ftpd, proftpd, squid, asterisk and dovecot.
+
+
+### A quick description of capabilities in Linux
+
+Each process has a three bit fields representing each of the three
+sets (P, E and I).  Each bit field is currently built up of two (32
+bit) integers to be able to hold the 33 currently defined capabilities
+(see linux/capability.h).  Each process further has a bounding set which
+bounds the permitted set.  Two syscalls handles the setting and getting
+of capabilities; *capset* and *capget*.  Some related functionality
+can also be controlled by calling *prctl*: the right to read/drop the
+bounding capabilities (PR_CAPBSET_READ/PR_CAPBSET_DROP) and whether
+or not the process should keep its capabilities when a change is made
+to the threads UID's (PR_SET_KEEPCAPS/PR_GET_KEEPCAPS).  User space
+applications are expected(recommended?) to use libcap to take advantage
+of the functionality provided.  Some applications also use libcap-ng
+which is "intended to make programming with POSIX capabilities much
+easier than  the traditional libcap library".  Most applications seem
+to be using the original libcap, however.
+
+
+## Implementing libcap
+
+The exercise for this assignment was to get the libcap used in
+Linux to compile under the Hurd.  This was accomplished using the
+latest git version of libcap from (..), corresponding to libcap
+2.19.  The changes were simple and amounted to simply removing the
+dependency on some Linux-specific headers and creating stubs for
+capset, capget and prctl described above.  This suggests that porting
+this library to the Hurd once the proper functionality is in place
+could be relatively simple.  The patch is available
+[here](https://alioth.debian.org/tracker/index.php?func=detail&aid=312442&group_id=30628&atid=410472 "Alioth").
+One could also consider implementing the three missing functions in the
+Hurd (or Hurd glibc) which would allow the usage of the Linux libcap
+without modifications.  As the Linux libcap maintainer might or might
+not be interested in making libcap multi platform, this approach might
+be preferable.
+
+
+## Implementing POSIX capabilities in the Hurd
+
+As I am still reading up on how things fit together in the Hurd this is
+very likely to contain some misunderstandings and be at least partly off
+the mark.  I intend to have grasped this by the time I start working on
+it however, if I were to be given the chance.  Below are two possible
+approaches as I have understood them after some reading and discussions
+on #hurd@freenode.
+
+
+### The basics, Approach 1: Special UID's
+
+Let each capability be represented by a specific UID.  One could imagine
+reserving a range of the possible uid_t's for this purpose.  The euids
+vector in the authhandle struct could perhaps hold the effective set while
+the auids vector could hold the permitted set as these seem to roughly
+correspond to eachother in intent.  This leaves the Inheritable set.
+One solution could be to store the inheritable set in the agids vector,
+but that does not seem to be a very natural nor nice solution.  One could
+extend the authhandle struct with an additional vector, but one would then
+need to also extend the auth interface with RPC's to be able to modify
+and access it.  Another possibility is to store all the capabilities
+in the same idvec and use separate defines for the the different sets
+(CAP_P_CHMOD, CAP_E_CHMOD, CAP_I_CHMOD).  This does not seem like a
+good solution.
+
+Storing each capability in its own uid_t might also arguably be somewhat
+wasteful, although this is probably of secondary concern (if at all).
+One could also imagine that legacy applications might be confused,
+although I am not sure I can see any obvious problems.  What happens
+when a process have only capability id's?
+
+
+### The basics, Approach 2: Extend the auth interface
+
+This approach would expand the auth interface and extend
+the auth server with another set of RPC's for capabilities
+(*auth_getcaps*, *auth_makecaps*, *auth_user_authenticate* and
+*auth_server_authenticate*), mirroring those currently declared for id's.
+This would obviously require changes to more parts of the Hurd for
+processes to be able to take advantage of capabilities, but as the logic
+behind handling capabilities and that behind handling user id's might
+not be completely comparable, this might make for a cleaner solution.
+It would also remove the problem of having to sensibly map all the
+three capability sets onto semantically differing sets of user/group
+ids, something that might be even more important if we were to also
+implement something like the bounding sets used in Linux or perhaps
+other related functionality.  We are also not limited to having to store
+the capabilities as id vectors, although doing so would perhaps still
+make sense.
+
+
+### The individual capabilities
+
+Implementing the individual capabilities will probably have to be thought
+of on a case-by-case basis.  Taking chown (in *libdiskfs*) as an example,
+the exact approach would differ slightly depending on how the approach
+taken to implement capabilities.  If the first approach were to be taken,
+the UID's (and thus the capabilities) of the caller would already be
+available to the function through the *iouser* struct contained in the
+*protid* struct given as the first argument.  Implementing capabilities
+would then simply be a matter of checking for the special UID's.  If the
+second approach were to be taken, one would need to perhaps expand the
+iouser struct to contain information about the capabilities.
+
+Just like Linux has defined many Linux-specific capabilities - some of
+which could certainly be useful also applied to the Hurd - one could
+also imagine extending the POSIX capability system also for Hurd specific
+purposes.
+
+
+## Some applications using capabilities
+
+#### Samba 3
+
+Uses CAP_MKNOD and CAP_LEASE in smbd to only keep the necessary abilities.
+Documentation mentions CAP_LINUX_IMMUTABLE as a way to protect files
+from being deleted.  Can also use a couple of IRIX specific capabilities
+(CAP_NETWORK_MGT and CAP_DEVICE_MGT) as alternatives to the Linux-specific
+ones if running on IRIX.
+
+
+#### ntpd
+
+Checks if capabilities are supported, more precisely if CAP_SYS_TIME,
+CAP_SETUID, CAP_SETGID, CAP_SYS_CHROOT and CAP_NET_BIND_SERVICE are
+supported.  If they are supported, it uses prctl with PR_SET_KEEPCAPS
+to keep privileges across setuid() and then drops root.  After done with
+CAP_SETUID, CAP_SETGID, CAP_SYS_CHROOT it drops every capability except
+CAP_SYS_TIME and, if needed, CAP_NET_BIND_SERVICE.
+
+
+#### vsftpd
+
+Uses CAP_CHOWN, CAP_NET_BIND_SERVICE when using the "one process"
+security model (typically disabled by default).
+
+
+#### proftpd-basic
+
+Provides support for capabilities from mod_cap.  Uses CAP_USE_CHOWN,
+CAP_USE_DAC_OVERRIDE, CAP_USE_DAC_READ_SEARCH and CAP_USE_AUDIT_WRITE.
+Distribution contains README.capabilities with some explanations.
+Also ships with their own libcap for some reason, based on libcap 1.10.
+
+
+#### dovecot
+
+Keeps CAP_CHOWN, CAP_SYS_CHROOT, CAP_SETUID, CAP_SETGID,
+CAP_NET_BIND_SERVICE, CAP_DAC_OVERRIDE for proper operations, drops
+the rest.
+
+
+#### bind9
+
+Reasons for each capability are clearly noted in comments in update.c
+in linux_initialprivs() and linux_minprivs().  initialprivs drops all
+capabilities and proceeds to set CAP_NET_BIND_SERVICE, CAP_SYS_CHROOT,
+CAP_SETUID, CAP_SETGID, CAP_DAC_READ_SEARCH and CAP_CHOWN.  minprivs only
+sets CAP_NET_BIND_SERVICE and CAP_SYS_RESOURCE.
+
+
+#### pulseaudio
+
+Mentions CAP_NICE (CAP_SYS_NICE), but does not appear to be using it
+(anymore?).  Seems to use libcap to drop caps, however.
+
+
+#### pinentry
+
+Checks if CAP_IPC_LOCK is available and "uses it" to gain only the
+ability to lock memory when needed.
+
+
+#### zsh
+
+Comes with a module "caps" which contains "[b]uiltins for manipulating
+POSIX.1e (POSIX.6) capability (privilege) sets." Most useful here is the
+"cap" builtin, which makes it possible to change the shell's process
+capability sets.  This might be useful for testing.
+
+
+#### inetutils (ping,traceroute)
+
+Does not use capabilities explicitly, but is nevertheless a useful
+example of how file capabilities could be used.  ping and traceroute
+are currently installed suid root since they need to be able to open
+raw sockets.  With file capabilities, this could be accomplished by
+instead setting the capability CAP_NET_RAW on the two executables,
+thus giving the utilities almost only the specific rights they need.
+
+
+## The capabilities
+
+The above might give some hint as to what capabilities should be
+prioritized.  One assumption I have made is that the goal of this project
+is to implement, as far as possible, the same functionality as what is
+present in Linux.  No effort has (so far) been made to look into possible
+applications specific to the Hurd.
+
+A few of the above mentioned applications also explicitly uses
+PR_SET_KEEPCAPS (through prctl()) to specify that capabilities should
+be passed on to children.  This means that the implementation in the
+Hurd should take this into account.
+
+I have below done a preliminary classification of the capabilities
+as defined in Linux capability.h into four "classes": Network, File
+management, "glibc -> mach" and Other.  There are also some capabilities
+that either depend on functionality not implemented or are too Linux
+specific.  I have not described each capability in detail as looking
+at the comments in capability.h and reading in capabilities(7) are
+better sources.
+
+
+### The Networking Class
+
+These would mostly affect pfinet.  The general picture seem to be that
+pfinet currently uses a boolean (int) isroot in struct sock_user to keep
+track of the credentials of the caller.  This would need to be expanded
+somehow to keep track of the separate capabilities.
+
+CAP_NET_BIND_SERVICE: Allow binding to TCP/UDP sockets below 1024  
+CAP_NET_RAW: Allow use of RAW and PACKET sockets.  
+CAP_NET_BROADCAST: "Allow broadcasting, listen to multicast"  
+CAP_NET_ADMIN: This seem to be a bit of a "catch-all" for network-related
+administration.  
+
+
+### The Files Management Class
+
+The description of CAP_CHOWN in the original proposal should apply to
+(most of?) these.  That is, modify the iouser struct.  At least libdiskfs
+should be modified, but the same or similar modifications might need to
+be made to several servers (libnetfs..? The actual servers implementing
+the filesystem?)
+
+CAP_CHOWN: "Make arbitrary changes to file UIDs and GIDs"  
+CAP_FOWNER: allow chmod, utime, ..  for files not owned.  
+CAP_FSETID: Don't clear setuid/setgid when a file is modified.  
+CAP_DAC_OVERRIDE and  
+CAP_DAC_READ_SEARCH: Bypasses file/directory read/write/execute permission
+checks.  ( hurdexec.c, file-access.c, ..  ? )  
+CAP_MKNOD: allows usage of "the privileged aspects of mknod()".  Does this
+one make sense in the Hurd?  
+
+
+### The (glibc -> gnumach) Class
+
+These seem to be implemented in glibc by direct calls to gnumach.
+If they should be implemented, maybe a proxy in the Hurd is needed?
+
+CAP_SYS_TIME: manipulate the system clock, set real-time clock.  
+CAP_IPC_LOCK: mlock, mlockall, mmap, shmctl  
+CAP_KILL: No permission checks for killing processes  
+CAP_SYS_NICE: setpriority/getpriority for arbitrary processes.  
+
+
+### The Rest Class
+
+CAP_SYS_CHROOT: Allows usage of chroot().  
+It's either really simple (not needed in the case of the Hurd) or really
+difficult.  Needs some figuring out.  One of the calls that should be
+high-priority.  
+CAP_SYS_ADMIN: General administration rights.  Seemingly sprinkled out
+into just about everything.  Quick grep through the Linux sources gives
+440 hits in .c-files.  
+CAP_SYS_BOOT: Allow use of reboot().  
+glibc calls init:startup_reboot..    
+CAP_SETGID: Allows usage of setgid,setgroups and "forged gids on socket
+credentials passing"  
+CAP_SETUID: Allows usage of set*uid and "forged pids on socket credentials
+passing"  
+CAP_SYS_TTY_CONFIG: vhangup, some other places.  vhangup() is a stub in
+the Hurd, but maybe the console server is otherwise affected?  
+CAP_SYS_RESOURCE: Override various limits.  (quota, reserved space etc.
+on ext2, interrupt frequencies, consoles,...).  According to "The Critique"
+mach performs no resource accounting so some of these might be moot to
+implement, while others still apply.  
+CAP_SYS_RAWIO Allow raw input/output.  Sprinkled in many places,
+device drivers among others.  Many of these will probably be difficult
+to implement.  
+CAP_SETPCAP: This one has (or had?) two different usages in Linux:
+If file capabilities are not supported it gives the right to grant
+or remove capabilities from the permitted set of arbitrary processes.
+If file capabilities are supported, it allows for removing capabilities
+from the bounding set of the current process.  As the Hurd implementation
+won't have file capabilities initially it might make sense to implement
+this if possible.  If bounding sets are implemented this should probably
+be the way provided to modify them.  
+
+
+### Unimplementable
+
+*(At this point in time, as far as I can determine)*
+
+CAP_LINUX_IMMUTABLE: depends on chattr etc. working.  
+CAP_SETFCAP: depends on xattr's  
+CAP_SYS_PACCT: acct() missing in the Hurd.  
+CAP_SYS_MODULE, CAP_SYS_PTRACE, CAP_MAC_OVERRIDE, CAP_MAC_ADMIN,
+CAP_AUDIT_WRITE, CAP_AUDIT_CONTROL, CAP_LEASE  
+
+
+## Priority when implementing
+
+The two most used capabilities as unscientifically judged from
+the selection of applications above are CAP_NET_BIND_SERVICE and
+CAP_CHOWN, suggesting that implementing the "network class" and the
+"file management" class of capabilities as classified above might be a
+good start.  These also, to me, seem to be easier classes to implement.
+CAP_NET_ADMIN might need some extra work.
+
+Second most common were CAP_SYS_CHROOT, CAP_SETGID and CAP_SETUID. I am
+not completely clear on how these should be handled.
+
+Assuming those are out of the way, CAP_IPC_LOCK, CAP_SYS_TIME, CAP_KILL
+and CAP_SYS_NICE might be a good choice to tackle if possible. This
+might, if I have understood things correctly, involve writing a proxy
+Hurd server for these calls in mach.
+
+CAP_SYS_ADMIN, CAP_SYS_RESOURCE and CAP_SYS_RAWIO. These contains a bit
+of "everything" (ADMIN being the worse one), meaning that experience
+and infrastructure gained from implementing the previous capabilities
+might come in handy. CAP_SYS_RAWIO might be difficult; it can be found
+inside many drivers in the Linux source.
+
+
+## Additional general details
+
+[This article](http://www.ibm.com/developerworks/library/l-posixcap.html)
+contains a good general description of how capabilities in Linux
+works.  As there will be no file capabilities in the Hurd initially,
+an approach emulating the behavior Linux exhibits when SECURE_NOROOT
+and SECURE_NO_SETUID_FIXUP are *not* set seems to be a good start.
+This is called the "root-user-is-privileged" model in the article,
+and somewhat simplified it means that processes started by root, or
+setuid-root, is given all capabilities no matter what capabilities the
+parent might or might not hold at the time of execution.  Quoting verbatim
+from the article:
+
+> * When SECURE_NOROOT is not set, then when a process executes a file,
+>  the new capability sets may be calculated as though the file had some
+>  file capability sets set fully populated.  In particular:
+>
+>  * The file inheritable and permitted sets will be full on if the
+>    process's real or effective uid is 0 (root) or the file is setuid
+>    root.
+>
+>  * The file effective set will be full on if the process's effective
+>    uid is root or the file is setuid root.
+>
+>
+> * When SECURE_NO_SETUID_FIXUP is not set, then when a process switches
+>   its real or effective uids to or from 0, capability sets are further
+>   shifted around:
+>
+>   * If a process switches its effective uid from 0 to non-0, then its
+>     effective capability set is cleared.
+>
+>   * If a process switches its real, effective, or saved uids from at
+>     least one being 0 to all being non-zero, then both the permitted
+>     and effective capabilities are cleared.
+>
+>   * If a process sets its effective uid from non-zero to 0, then the
+>     effective capabilities are set equal to the permitted capabilities.
+
+The capabilities of the resulting process are determined by the following
+formulas, again taken from the article, with p for Process and f for file:
+
+> pI' = pI  
+> pP' = fP | (fI & pI)  
+> pE' = pP' & fE  
+
+The security under the above described model, being what at least some
+of the applications I listed in my last comment employs, is basically
+the following (also detailed somewhat in the same article):
+
+* Execute process as root (or setuid) to gain all capabilities.
+
+* Use the prctl system call to enable keepcaps for the process
+  (same(?) effect as enabling SECURE_NO_SETUID_FIXUP for the process).
+  keepcaps should be off by default.
+
+* setuid to a non-root user, and by doing so losing the possibility to
+  regain capabilities by simply starting a new process.
+
+* Drop all the capabilities except those few actually needed.
+
+
+## Infrastructure details - Special UIDs approach
+
+The auth server must somehow keep track of three sets of capabilities.
+I suggest keeping these three sets in three additional idvec's in the
+authhandle struct, and will for the purpose of this description name
+these pcaps (permitted), ecaps (effective) and icaps (inheritable).
+This will simplify keeping track of the internal logic somewhat.
+In addition to this, there is a need to keep track of the "keepcaps" flag
+as described above.  I suggest representing this with an int keepcaps
+in the same struct.
+
+1. Expand authhandle struct with three additional idvecs and one integer.
+Fix static functions handling the struct, such as destroy_authhandle.
+
+2. Implement the necessary logic in auth_makeauth to handle capabilities.
+
+Problems:  
+Assume that all capabilities are mapped onto uids, given names on the form
+uid_<capability>, for example uid_cap_net_raw.  Assume that the presence
+of an uid in euids suggest that the capability is in the effective set
+of the process, that the presence of this uid in auids suggests that it
+is in the permitted set of the process, and that the presence of this
+uid in aguids suggest that it is in the inheritable set of the process.
+That they are internally stored in separate idvec's can be ignored as
+an implementation detail.
+
+* The UID's have as it is different meanings depending on where in the
+  array they are positioned, and certain clients seem to rely on this.
+  The first UID in euids is the effective uid, and the first and second
+  UIDs in auids are the real and saved UIDS respectively.  At least
+  some users of makeauth would need to made aware of capabilities,
+  for example setuid in glibc.
+
+* Setting/getting the keepcaps-flag is also a bit of a problem.  To avoid
+  changing the auth interface yet another special UID could be used
+  for this purpose, although that seems to be really stretching it.
+  The cleaner solution would probably be to expand the interface with
+  something along the lines of auth_setkeepcaps/auth_getkeepcaps.
+  This interface would only be used by prctl.
+
+Another problem with this approach is that it seems a bit difficult
+to oversee the affects that using other RPC's like fsys_getroot and
+io_restrict_auth might have on capabilities.
+
+
+## Infrastructure details - "extend-interfaces" approach
+
+This approach has started to seem like the better way to me, as the
+usage of capabilities becomes more explicit through the entire "chain",
+perhaps making it somewhat more easy to understand all the interactions.
+
+I suggest something like the following new interface methods:
+
+***
+
+
+### The auth interface
+
+	routine auth_getauth_caps (
+		handle: auth_t;
+		out euids: idarray_t;
+		out auids: idarray_t;
+		out egids: idarray_t;
+		out agids: idarray_t;
+		out ecaps: idarray_t;
+		out pcaps: idarray_t;
+		out icaps: idarray_t);
+
+	routine auth_makeauth_caps (
+		handle: auth_t;
+		other_handles: portarray_t;
+		euids: idarray_t;
+		auids: idarray_t;
+		egids: idarray_t;
+		agids: idarray_t;
+		ecaps: idarray_t;
+		pcaps: idarray_t;
+		icaps: idarray_t;
+		flags: int;   /* keepcaps.. ? */
+		out newhandle: mach_port_make_send_t);
+
+	routine auth_server_authenticate_caps (
+		handle: auth_t;
+		sreplyport reply: mach_port_poly_t;
+		rendezvous: mach_port_send_t;
+		newport: mach_port_poly_t;
+		out euids: idarray_t;
+		out auids: idarray_t;
+		out egids: idarray_t;
+		out agids: idarray_t;
+		out ecaps: idarray_t;
+		out pcaps: idarray_t;
+		out icaps: idarray_t);
+
+
+### The io interface
+
+	routine io_restrict_auth_caps (
+		io_object: io_t;
+		RPT
+		out new_object: mach_port_send_t;
+		uids: idarray_t SCP;
+		gids: idarray_t SCP;
+		ecaps: idarray_t SCP);
+
+
+### The fsys interface
+
+	routine fsys_getroot_caps (
+		fsys: fsys_t;
+		RPT
+	#ifdef  FSYS_GETROOT_UREPLY
+		ureplyport ureply: mig_reply_port_t;
+	#endif
+		dotdot_node: mach_port_send_t;
+		gen_uids: idarray_t;
+		gen_gids: idarray_t;
+		out ecaps: idarray_t;
+		out pcaps: idarray_t;
+		out icaps: idarray_t;
+		flags: int;
+		out do_retry: retry_type;
+		out retry_name: string_t;
+		out file: mach_port_send_t);
+
+***
+
+These are meant to be able to replace the old methods with
+capability-aware methods, instead of merely complementing them.
+The replacing work could then be made a more gradual process.  Steps:
+
+* Extend authhandle with the same data members as in the UID-case.
+
+* Implement new _caps-functions according to described interface
+  extensions above, refactor code a bit to share common uid-handling
+  logic.  Both makeauth's should drop all capabilities if switching from
+  uid 0 without having keepcaps.  For example, keepcaps should be unset
+  by default.
+
+* Fix glibc.  Extend hurd_id_data in hurd/id.h to store capabilities,
+  switch to capability aware functions where necessary.
+
+* io-reauthenticate.  Fix implementations to use
+  auth_server_authenticate_caps instead.  For this we also need somewhere
+  to save the caps, so it ties in with for example the extension of
+  iouser as mentioned in the details.
+
+* fsys_getroot.  Implement fsys_getroot_caps in libdiskfs, trans,
+  libtreefs, libtrivs, libnetfs.  Fix users of function in libdiskfs,
+  libfshelp, settrans, libtreefs, clookup.
+
+* io_restrict_auth.  Implement io_restrict_auth_caps in libdiskfs,
+  libtreefs, libtrivfs, libnetfs, boot.  Fix users in utils(symlink,
+  firmlink), libtrivs, term, clookup
+
+Among the problems might be that there are a lot of arguments that
+needs to be passed around, and that it seems somewhat ugly to end up
+with function names referencing caps in particular.
+
+Below some more about the specific capabilities.  This should in large
+be common to the two approaches above.
+
+
+## Actually handing out the capabilities to process
+
+This seems like a good job for the file_exec route in the fs interface.
+Quoting from the comments above the definition in fs.defs: "*Necessary
+initialization, including authentication changes associated with set[ug]id
+execution must be handled by the filesystem*".  The capability-granting
+functionality should to be added in at least the implementations in
+libdiskfs and libnetfs as far as I can determine, and should be "easy
+enough" once the infrastructure for implementing the file-related
+capabilities (CAP_CHOWN etc.) are in place.  This also seem to make
+sense considering the future possibility for file capabilities.
+
+
+## Some implementation details of individual capabilities.
+
+### Net-related capabilities.
+
+This turned out to be a bit less work than I had thought, as the
+imported Linux code already seem to contain all the necessary checks.
+What remains to do to implement all of these capabilities is mostly a
+matter of putting some infrastructure in place.
+
+* In struct sock_user (pfinet.h), change isroot for idvec
+  caps.  Alternatively, add idvec caps.
+
+* Change the function make_sock_user in socket.c to take an idvec caps
+  as a parameter and properly set the given caps to the corresponding
+  idvec in sock_user.
+
+* Fix users of make_sock_user: S_io_reauthenticate, S_io_restrict_auth,
+  S_socket_create, S_socket_accept.  This should be doable with the
+  current infrastructure.  For example, S_socket_create currently
+  sets isroot in the new sock_user from the corresponding member in
+  the trivfs_protid struct.  This does not present a problem however,
+  as the latter struct also provides access to an iouser (iohelp.h)
+  from which the needed uids of the user should be available.
+
+* Fix up parts of source from Linux, modify task_struct add idvec,
+  modify prepare_current to take the caps idvec instead of isroot.
+  Re-implement the existing function capable(int cap) to actually check
+  for the capability passed as an argument instead of just return isroot.
+
+* Change a few isroot's at 3 other places in the code to check for
+  capabilities.  Since these places all have access to isroot and thus by
+  implication the sock_user, they also have access to the new capability
+  information; no restructuring necessary.
+
+
+### File-related capabilities
+
+While there are a lot of servers in the Hurd, I am not sure all of these
+capabilities actually make sense to implement in all of them.
+
+
+#### CAP_CHOWN
+
+Implementing this in libdiskfs should take care of it where it makes
+sense.  Servers using libdiskfs uses iouser from libiohelp to hold
+user credentials.  As noted above, this struct is already capable of
+holding our capabilities as uid's or is otherwise extended to contain
+the necessary idvecs if using the second general approach.  Adding a
+check along the lines of *idvec_contains(uid_cap_chown)* in function
+diskfs_S_file_chown (file-chown.c) should be all that's needed.
+
+In libnetfs, netfs_attempt_chown is declared as a function that the
+server using the library must implement.  Any checks for chown rights
+are however most likely performed on the server side, suggesting that
+there is nothing we can do here to implement CAP_CHOWN.  Even if we do
+need to add something, an iouser containing the necessary information
+to implement the checks in a manner analogous to that in libdiskfs seems
+to be passed to each important function.
+
+
+#### CAP_DAC_*
+
+These might actually make sense to implement in more servers, and the
+logic seems somewhat involved. Need to add the necessary checks to
+at least file_check_access, file_exec in libdiskfs.  file_exec also in
+libnetfs, probably.  Possibly changes also in other places.
+
+The main difficulties overall seem to lie in getting the infrastructure
+properly in place rather than implementing most of the individual
+capabilities, and I have updated the schedule a bit in an attempt to
+reflect this.
+
+
+## Schedule updating
+
+The more I look into this the less time it seems likely to take to
+do the work.  Below is my best estimation at the moment, and I have
+basically adjusted everything to what I think is more likely estimations.
+If this is correct I would be more or less around midterm.  I haven't
+gone completely to the individual level as that doesn't seem to make
+sense, but what is clustered together are either related capabilities
+or a collection of capabilities classified roughly with regards to how
+much I know about the area and how many different rights they control.
+It's not my intention to "slack off" or anything, so if this estimation
+were to be correct I could perhaps take a look at the xattrs-patch,
+or spend the rest of my time fixing PATH_MAX-issues.  Then again, maybe
+there is some great difficulty hidden somewhere.
+
+
+#### Some justifications:
+
+Dummy libcap, more or less done.  
+*1 day* (making sure it "fails gracefully" shouldn't really take longer than this)
+
+Application for testing, the beginnings of a fairly extensive "test suit" on Linux.  
+*2 days*
+
+Basic infrastructure.  
+*5 days*, depends on the chosen approach, but it is probably wise to
+reserve at least a bunch of days for this.
+
+Implementations of prctl/capset/capget in libshouldbeinlibc,
+or a port of libcap to the Hurd in any other way.  
+*5 days*
+
+CAP_NET_BIND_SERVICE, CAP_NET_RAW, CAP_NET_BROADCAST, CAP_NET_ADMIN  
+*4 days*, as noted above this should be easy, but it might uncover bugs
+in the newly implemented infrastructure for example.
+
+CAP_CHOWN,CAP_FOWNER,CAP_FSETID  
+*2 days*, I think these only needs to be done in libdiskfs
+
+CAP_DAC_OVERRIDE,CAP_DAC_READ_SEARCH  
+*4 days*, these might need changes to various servers
+
+CAP_SYS_TIME,CAP_IPC_LOCK,CAP_KILL
+CAP_SYS_NICE,CAP_SYS_CHROOT,CAP_SYS_BOOT  
+*2 weeks*, these are varied and I'm not that sure exactly how each should
+be tackled so some research is needed.
+
+CAP_SETGID,CAP_SETUID,CAP_SYS_TTY_CONFIG  
+*4 days*
+
+CAP_SYS_ADMIN,CAP_SYS_RESOURCE,CAP_SYS_RAWIO  
+*2 weeks*, these too are pretty varied and some might need some individual
+researching
+
+CAP_SETPCAP  
+*1 day*
+
+
+## Schedule
+
+24/5 Start coding  
+25/5 Dummy libcap ready for use.  
+27/5 The beginnings of a "test suite", written on Linux.  
+ 1/6 Basic infrastructure in place  
+ 6/6 Dummy libcap extended with real functionality to make use of
+     implemented capability and infrastructure, or the Hurd adapted for
+     compatibility with Linux libcap.  
+10/6 The "network class" of capabilities implemented.  
+12/6 CAP_CHOWN, CAP_FOWNER, CAP_FSETID  
+16/6 CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH  
+30/6 CAP_SYS_TIME, CAP_IPC_LOCK, CAP_KILL, CAP_SYS_NICE,
+     CAP_SYS_CHROOT, CAP_SYS_BOOT  
+ 4/7 CAP_SETGID,CAP_SETUID,CAP_SYS_TTY_CONFIG  
+12/7 "Mentors and students can begin submitting mid-term evaluations"  
+16/7 GSoC Mid-term evaluations deadline.  
+18/7 CAP_SYS_ADMIN, CAP_SYS_RESOURCE, CAP_SYS_RAWIO  
+19/7 CAP_SETPCAP