summaryrefslogtreecommitdiff
path: root/community/gsoc/project_ideas
diff options
context:
space:
mode:
Diffstat (limited to 'community/gsoc/project_ideas')
-rw-r--r--community/gsoc/project_ideas/libcap.mdwn8
-rw-r--r--community/gsoc/project_ideas/libcap/details.mdwn8
-rw-r--r--community/gsoc/project_ideas/secure_chroot.mdwn11
-rw-r--r--community/gsoc/project_ideas/valgrind.mdwn8
4 files changed, 18 insertions, 17 deletions
diff --git a/community/gsoc/project_ideas/libcap.mdwn b/community/gsoc/project_ideas/libcap.mdwn
index 1346203d..18c49c48 100644
--- a/community/gsoc/project_ideas/libcap.mdwn
+++ b/community/gsoc/project_ideas/libcap.mdwn
@@ -1,12 +1,12 @@
-[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
[[!meta title="Implementing libcap"]]
@@ -33,7 +33,7 @@ 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]].
+he fleshed out many [[details]].
Possible mentors: Samuel Thibault (youpi)
diff --git a/community/gsoc/project_ideas/libcap/details.mdwn b/community/gsoc/project_ideas/libcap/details.mdwn
index aa27a84e..85695978 100644
--- a/community/gsoc/project_ideas/libcap/details.mdwn
+++ b/community/gsoc/project_ideas/libcap/details.mdwn
@@ -5,8 +5,8 @@ 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
[[!meta title="Details on implementing libcap"]]
@@ -59,7 +59,7 @@ 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
+bounds the permitted set. Two [[system call]]s 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
@@ -428,7 +428,7 @@ 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
+* 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.
diff --git a/community/gsoc/project_ideas/secure_chroot.mdwn b/community/gsoc/project_ideas/secure_chroot.mdwn
index feb30a7c..57739861 100644
--- a/community/gsoc/project_ideas/secure_chroot.mdwn
+++ b/community/gsoc/project_ideas/secure_chroot.mdwn
@@ -1,17 +1,18 @@
-[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2008, 2009, 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
[[!meta title="Secure chroot Implementation"]]
As the Hurd attempts to be (almost) fully [[UNIX]]-compatible, it also implements a
-`chroot()` system call. However, the current implementation is not really
+`chroot` [[system call]]. However, the current implementation is not really
good, as it allows easily escaping the `chroot`, for example by use of
[[passive_translators|hurd/translator]].
@@ -20,7 +21,7 @@ workaround changing the behavior of passive translators in a `chroot`;
changing the context in which passive translators are executed; changing the
interpretation of filenames in a chroot; to reworking the whole passive
translator mechanism. Some involving a completely different approach to
-`chroot` implementation, using a proxy instead of a special system call in the
+`chroot` implementation, using a proxy instead of a special [[system call]] in the
filesystem servers.
See <http://tri-ceps.blogspot.com/2007/07/theory-of-filesystem-relativity.html>
diff --git a/community/gsoc/project_ideas/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn
index c6fc7459..7d68e82d 100644
--- a/community/gsoc/project_ideas/valgrind.mdwn
+++ b/community/gsoc/project_ideas/valgrind.mdwn
@@ -18,7 +18,7 @@ although they work on Linux.
Even more importantly, it will help finding bugs in the Hurd servers themselfs.
To keep track of memory use,
-Valgrind however needs to know how each system call affects the validity of memory regions.
+Valgrind however needs to know how each [[system call]] affects the validity of memory regions.
This knowledge is highly kernel-specific,
and thus Valgrind needs to be explicitely ported for every system.
@@ -26,11 +26,11 @@ Such a port involves two major steps:
making Valgrind understand how kernel traps work in general on the system in question;
and how all the individual kernel calls affect memory.
The latter step is where most of the work is,
-as the behaviour of each single system call needs to be described.
+as the behaviour of each single [[system call]] needs to be described.
Compared to Linux,
Mach (the microkernel used by the Hurd) has very few kernel traps.
-Almost all system calls are implemented as RPCs instead --
+Almost all [[system call]]s are implemented as RPCs instead --
either handled by Mach itself, or by the various Hurd servers.
All RPCs use a pair of mach\_msg() invocations:
one to send a request message, and one to receive a reply.
@@ -62,7 +62,7 @@ The goal of this task is at minimum to make Valgrind grok Mach traps,
and to implement the generic RPC handler.
Ideally, specific handling for RPCs needing it should also be implemented.
-Completing this project will require digging into Valgrind's handling of system calls,
+Completing this project will require digging into Valgrind's handling of [[system call]]s,
and into Hurd RPCs.
It is not an easy task, but a fairly predictable one --
there shouldn't be any unexpected difficulties,