Re: unable to include capability.h
Steve Grubb wrote: On Friday 12 June 2009 09:02:39 am Daniel Lezcano wrote: As I only need the CAP_SYS_BOOT, I will define it manually in the source code and will remove the include, that's ugly but anyway... :/ Alternatelyas of today, libcap-ng is now in Fedora. It has a far simpler API and you should be able to do things in 2-3 lines of code. For example, if you wanted to use it to retain only CAP_SYS_BOOT, the code would be: capng_clear(CAPNG_SELECT_BOTH); capng_update(CAPNG_ADD, CAPNG_EFFECTIVE|CAPNG_PERMITTED, CAP_SYS_BOOT); capng_apply(CAPNG_SELECT_CAPS); You're done. If you know you application has no children, then you would want to change the last line to use CAPNG_SELECT_BOTH so that the bounding set is cleared. libcap-ng has 1 relocation and libcap has 35, so it starts up faster. Its also smaller in size and has better analysis tools. More info can be found here: http://people.redhat.com/sgrubb/libcap-ng/ I'll be setting up a Fedora 12 project in the next few days to drop privs everywhere. Interesting. Thanks for the information. -- Daniel -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: unable to include capability.h
On Friday 12 June 2009 09:02:39 am Daniel Lezcano wrote: > As I only need the CAP_SYS_BOOT, I will define it manually in the source > code and will remove the include, that's ugly but anyway... :/ Alternatelyas of today, libcap-ng is now in Fedora. It has a far simpler API and you should be able to do things in 2-3 lines of code. For example, if you wanted to use it to retain only CAP_SYS_BOOT, the code would be: capng_clear(CAPNG_SELECT_BOTH); capng_update(CAPNG_ADD, CAPNG_EFFECTIVE|CAPNG_PERMITTED, CAP_SYS_BOOT); capng_apply(CAPNG_SELECT_CAPS); You're done. If you know you application has no children, then you would want to change the last line to use CAPNG_SELECT_BOTH so that the bounding set is cleared. libcap-ng has 1 relocation and libcap has 35, so it starts up faster. Its also smaller in size and has better analysis tools. More info can be found here: http://people.redhat.com/sgrubb/libcap-ng/ I'll be setting up a Fedora 12 project in the next few days to drop privs everywhere. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: unable to include capability.h
Kyle McMartin wrote: ... Someone else suggested including first, which should work around it. That's what GNU coreutils did... (a change in the include ordering broke it.) I'm surprised the man page for cap_get_flag etc don't show an include of before ... many system call man pages do e.g. -- NAME open, creat - open and possibly create a file or device SYNOPSIS #include #include #include int open(const char *pathname, int flags); int open(const char *pathname, int flags, mode_t mode); int creat(const char *pathname, mode_t mode); -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: unable to include capability.h
On Fri, Jun 12, 2009 at 03:24:45PM +0200, Daniel Lezcano wrote: > Correct. I tried with different distro lenny, ubuntu 8.04, fedora 10, > opensuse 11 and I hadn't this problem. > It was a local Fedora patch that tickled it with recent kernels, Karsten has sorted it out (but too late for Fedora 11 release... should be fixed in updates?) Thanks for sorting it out Karsten. * Mon Jun 08 2009 Karsten Hopp 2.16-3 - disable headerfix patch (#503927) cheers, kyle -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: unable to include capability.h
Kyle McMartin wrote: On Fri, Jun 12, 2009 at 03:02:39PM +0200, Daniel Lezcano wrote: Grumf ! that's annoying :( Thank you very much for your quick answer ! :) As I only need the CAP_SYS_BOOT, I will define it manually in the source code and will remove the include, that's ugly but anyway... :/ As I understood, the fix in the kernel conflicts with the workaround in userspace, right ? I was wondering if I should notify this to the maintainer of the libcap or is it already known ? Someone else suggested including first, which should work around it. That's what GNU coreutils did... (a change in the include ordering broke it.) Ah yes, I prefer this workaround, it is cleaner. Thanks for the the trick, I tested it and that solved the issue. Which release are you seeing this on... F-11? Correct. I tried with different distro lenny, ubuntu 8.04, fedora 10, opensuse 11 and I hadn't this problem. Thanks. -- Daniel -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: unable to include capability.h
On Fri, Jun 12, 2009 at 03:02:39PM +0200, Daniel Lezcano wrote: > Grumf ! that's annoying :( > > Thank you very much for your quick answer ! :) > > As I only need the CAP_SYS_BOOT, I will define it manually in the source > code and will remove the include, that's ugly but anyway... :/ > > As I understood, the fix in the kernel conflicts with the workaround in > userspace, right ? > I was wondering if I should notify this to the maintainer of the libcap > or is it already known ? > Someone else suggested including first, which should work around it. That's what GNU coreutils did... (a change in the include ordering broke it.) Which release are you seeing this on... F-11? cheers, Kyle -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: unable to include capability.h
Kyle McMartin wrote: On Fri, Jun 12, 2009 at 01:48:15PM +0200, Daniel Lezcano wrote: In file included from /usr/include/sys/capability.h:23, from myinclude.c:1: /usr/include/stdint.h:41: error: conflicting types for ?int64_t? /usr/include/linux/types.h:98: note: previous declaration of ?int64_t? was here /usr/include/stdint.h:56: error: conflicting types for ?uint64_t? /usr/include/linux/types.h:96: note: previous declaration of ?uint64_t? was here make: *** [myinclude] Error 1 is /still/ broken. there was a bug filed against the kernel, but the problem is actually the userspace header, which 'cheats' the preprocessor rather badly: #include #include /* * Make sure we can be included from userland by preventing * capability.h from including other kernel headers */ #define _LINUX_TYPES_H #define _LINUX_FS_H #define __LINUX_COMPILER_H #define __user typedef unsigned int __u32; typedef __u32 __le32; #include Grumf ! that's annoying :( Thank you very much for your quick answer ! :) As I only need the CAP_SYS_BOOT, I will define it manually in the source code and will remove the include, that's ugly but anyway... :/ As I understood, the fix in the kernel conflicts with the workaround in userspace, right ? I was wondering if I should notify this to the maintainer of the libcap or is it already known ? Thanks -- Daniel -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: unable to include capability.h
Daniel P. Berrange wrote: > On Fri, Jun 12, 2009 at 01:48:15PM +0200, Daniel Lezcano wrote: > > Is there a trick for that or is it a bug ? > > Adding #include seems to fix it, so I reckon its a bug in > libcap-devel's header files. Actually already reported and closed rawhide, so it should be fixed there... https://bugzilla.redhat.com/show_bug.cgi?id=483548 Greetings, Ondřej Vašík signature.asc Description: Toto je digitálně podepsaná část zprávy -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: unable to include capability.h
On Fri, Jun 12, 2009 at 01:48:15PM +0200, Daniel Lezcano wrote: > In file included from /usr/include/sys/capability.h:23, > from myinclude.c:1: > /usr/include/stdint.h:41: error: conflicting types for ?int64_t? > /usr/include/linux/types.h:98: note: previous declaration of ?int64_t? > was here > /usr/include/stdint.h:56: error: conflicting types for ?uint64_t? > /usr/include/linux/types.h:96: note: previous declaration of ?uint64_t? > was here > make: *** [myinclude] Error 1 > is /still/ broken. there was a bug filed against the kernel, but the problem is actually the userspace header, which 'cheats' the preprocessor rather badly: #include #include /* * Make sure we can be included from userland by preventing * capability.h from including other kernel headers */ #define _LINUX_TYPES_H #define _LINUX_FS_H #define __LINUX_COMPILER_H #define __user typedef unsigned int __u32; typedef __u32 __le32; #include nasty... cheers, kyle -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: unable to include capability.h
On Fri, Jun 12, 2009 at 01:48:15PM +0200, Daniel Lezcano wrote: > Hi, > > I hope this is the right mailing list ... > > I installed a f11 and tried to compile a simple program: > > #include > int main(int argc, char *argv[]) > { > return 0; > } > > But the compilation fails with the error: > > In file included from /usr/include/sys/capability.h:23, > from myinclude.c:1: > /usr/include/stdint.h:41: error: conflicting types for ?int64_t? > /usr/include/linux/types.h:98: note: previous declaration of ?int64_t? > was here > /usr/include/stdint.h:56: error: conflicting types for ?uint64_t? > /usr/include/linux/types.h:96: note: previous declaration of ?uint64_t? > was here > make: *** [myinclude] Error 1 > > Is there a trick for that or is it a bug ? Adding #include seems to fix it, so I reckon its a bug in libcap-devel's header files. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: unable to include capability.h
On Fri, 2009-06-12 at 13:48 +0200, Daniel Lezcano wrote: > Hi, > > I hope this is the right mailing list ... No, it is not. The right one is fedora-list, this one is for development of Fedora. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list