path: root/community/gsoc/project_ideas/libcap/details.mdwn
diff options
authorCarl Fredrik Hammar <>2010-04-20 19:01:04 +0200
committerCarl Fredrik Hammar <>2010-04-20 19:01:04 +0200
commit3896ffc39d0b1fa22762af4513047daaab558722 (patch)
tree7c6b107ebcb55d62f8b2c3851809dfdbfdbd875a /community/gsoc/project_ideas/libcap/details.mdwn
parent749475ce31c1650e0c5299148f78200e60e29a4f (diff)
Integrated David Hedberg's GSoC proposal
Needs more work but the formatting is reasonable. He gave his permission on IRC.
Diffstat (limited to 'community/gsoc/project_ideas/libcap/details.mdwn')
1 files changed, 766 insertions, 0 deletions
diff --git a/community/gsoc/project_ideas/libcap/details.mdwn b/community/gsoc/project_ideas/libcap/details.mdwn
new file mode 100644
index 0000000..aa27a84
--- /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
+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](;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
+## 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,
+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
+#### 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,
+Distribution contains README.capabilities with some explanations.
+Also ships with their own libcap for some reason, based on libcap 1.10.
+#### dovecot
+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,
+#### 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
+### 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_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
+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
+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.
+## 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.
+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](
+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.
+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;
+ 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;
+ 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.
+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*
+*4 days*, as noted above this should be easy, but it might uncover bugs
+in the newly implemented infrastructure for example.
+*2 days*, I think these only needs to be done in libdiskfs
+*4 days*, these might need changes to various servers
+*2 weeks*, these are varied and I'm not that sure exactly how each should
+be tackled so some research is needed.
+*4 days*
+*2 weeks*, these too are pretty varied and some might need some individual
+*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/7 "Mentors and students can begin submitting mid-term evaluations"
+16/7 GSoC Mid-term evaluations deadline.