[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GSoC] Implementing libcap

From: olafBuddenhagen
Subject: Re: [GSoC] Implementing libcap
Date: Fri, 1 Apr 2011 19:25:50 +0200
User-agent: Mutt/1.5.20 (2009-06-14)


On Wed, Mar 30, 2011 at 11:12:49AM +0300, Esa-Matti Mourujärvi wrote:
> On Wed, Mar 30, 2011 at 5:29 AM,  <olafBuddenhagen@gmx.net> wrote:
> > On Mon, Mar 28, 2011 at 10:44:29PM +0300, Esa-Matti Mourujärvi
> > wrote:

> > 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.

Me too... It's obviously a Linux-specific thing.

> >> 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]

I see... So capget()/capset()/prctl() are the actual low-level functions
provided by the kernel (through glibc); while libcap is a higher-level
interface on top of them?

> > 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.

Well, I actually meant adding this dummy header to the libcap package
itself... But avoiding any modification to the actual libcap code.

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

> 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,

Actually, it's perfectly resonable IMHO :-)

> and I am quite sure hurd has policies against this.

Not really. We try to avoid adding random bits of foreign code to Hurd
itself, to keep the copyright situation simple. This is about porting
libcap though, not about additions to the actual Hurd code...

> I have no idea what that particular ifdef-else-endif structure
> actually even does, my googleing failed in vain, but it seemed rather
> important.

Oh... That might be a problem. This level of C understanding will
probably be required to successfully complete this task...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]