Re: [GSoC] Implementing libcap

[Esa-Matti Mourujärvi]

On Wed, Mar 30, 2011 at 5:29 AM,  <olafBuddenhagen@gmx.net> wrote:
> 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 :-)
>
Hi, and thank you. :-)

>> 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.
>
Nor do I. To be honest, this is the first time I have even seen it being
used. This caused me some problems.

> 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?...
>
They way I have understood it, libcap works as an interface for setting
/ getting capabilities. capget, capset and prctl functions and the
capabilities themselves lie somewhere else, or as in this case not
implemented yet.

Missing capget, capset and prctl functions should be implemented either
into libcap package or as the idea's page suggests:

"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."[1]

The above quote also supports your view about just providing a pseudo
linux/types.h, so that we wouldn't need to make a separate hurd
package for libcap or to have the possible changes made to upstream.

The more I have studied this, the more I feel the GSoC idea's topic is
a bit misinformative. I think it should say "Implementing capabilities"
instead.

>> 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?
>
IMO, that solution would be a better one for sure, then we wouldn't need
a hurd specific package for libcap, as mentioned earlier.

>> +#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-
>
To my shame, I took the ifdef-else-endif structure from the real linux/types.h.
I know it might not be right thing to do, and I am quite sure hurd has policies
against this. I did this because of my inexperience how to handle __le32.
I have no idea what that particular ifdef-else-endif structure actually even
does, my googleing failed in vain, but it seemed rather important.

Just directly typedeffing __u32 to __le32 could had been problematic, which
is why I wanted to show the problem caused by the __le32 type, and hopefully
open an discussion for a proper solution.

[1] http://www.gnu.org/software/hurd/community/gsoc/project_ideas/
libcap/details.html

- Esa-Matti Mourujärvi / sukeri