Re: [GSoC] Implementing libcap

[olafBuddenhagen]

Hi,

On Mon, Mar 28, 2011 at 10:44:29PM +0300, Esa-Matti Mourujärvi wrote:

> I'm interested in applying for Hurd in GSoC. I am a second year CS
> student in University of Oulu, Finland.

Welcome :-)

> I have knowledge of C to some extend, but I have never developed
> anything big with it on my own. On another note, I have used
> non-windows operating systems only for a year, but I am eager to learn
> more.

These could be problems... Though your patch seems to indicate that you
already know the ways pretty well :-)

> What I am particularly interested in GSoC is the idea for implementing
> libcap for Hurd. I have managed to compile it on qemu Hurd by doing
> dummy patch. The main purpose of the mentioned patch (can be found
> from the bottom of this mail) is to prove it is easy and possible to
> port libcap to Hurd.

Well, it doesn't exactly prove that... But it's certainly a start :-)

> The solution I made is not most likely the elegant one possible.

Actually, I considered proposing something like that myself... It's the
most pragmatical approach for now -- though I guess a more elegant one
might be necessary for getting it upstream.

> I do realise, that another solution could be to change every variable
> type to the ones defined in stdint.h and send a patch to libcap's
> owner.

Yeah, I think that would be the *right* way of doing it. I'm not sure
however how __le32 could be handled properly in this case.

Also the question is whether the libcap maintainers want it... If we
have to maintain our own fork, the pragmatic solution is probably
preferable.

> Unfortunately I have not been able to actually test libcap by using
> capget/ capset functions, because gcc fails to link against them.

I don't understand. Aren't these what libcap is actually supposed to
provide?...

> My next plan is to study more about capabilities and about how user
> authentication currently works in Hurd. I also should learn somehow
> where exactly should one implement the missing capabilities. Any
> suggestions what else should I study in order to be able to send a
> proper application?

That should get you started pretty well I'd say :-)

> -#include <linux/types.h>
> +#include "typeswrapper.h"

Alternatively, perhaps we could just provide a pseudo linux/types.h with
the contents of typeswrapper.h?

> +#ifdef __CHECKER__
> +#define __bitwise__ __attribute__((bitwise))
> +#else
> +#define __bitwise__
> +#endif
> +#ifdef __CHECK_ENDIAN__
> +#define __bitwise __bitwise__
> +#else
> +#define __bitwise
> +#endif
> +
> +typedef __u32 __bitwise __le32;

OK, this part is a bit tricky... Could you try to explain it?

AIUI, it defines __le32 equal to __u32, except that it adds
__attribute__((bitwise)) if both __CHECKER__ and __CHECK_ENDIAN__ are
defined, so that sparse can warn on mismatches.

However, I'm not sure whether the intemediate __bitwise__ and __bitwise
symbols are used anywhere else? Otherwise, the multi-step definition
seems circuitous... Or did you take it directly from the real
linux/types.h?

-antrik-