Hello Kaigai -
Thank you for the response...
On Wed, Dec 13, 2006 at 11:43:51PM +0900, KaiGai Kohei wrote:
|
| Bill O'Donnell wrote:
| >Hello Kaigai -
| >
| >I'm hoping that you can clear something up for me, regarding fs caps.
| >I've been having good luck with Serge's patch, coupled with your
| >userspace tools (libcap-1.10-25.kg.2.src.tar.gz). I'm finding that
| >if I displace /lib/libcap.so with your version, enhanced file capabilities
| >are realized. This seems to be the case, regardless of the previous
| >version of libcap. As I had previously indicated, SLES-10 uses a very
| >old version of libcap (.92), while RHEL-5 and most other distros I've
| >tried use a newer version (.10). My question is this: should it even
| >matter what version of libcap is in place, since your userspace tools
| >displace whatever is there? Sorry, but this has me a bit confused ;)
|
| I didn't change any implementation of libcap-xxx-kg between the first and
| the second excluding a boundary condition of the array of capability names.
| Therefore, you will confront a matter as Hank Xu did, if libcap-1.10-25.kg.2
| is applied on SLES-10.
|
| There is one other approach. Is it possible to build getfcaps and setfcaps
| statically? If so, you didn't need to displace the original libcap provided
| by distributors.
|
| If you feel it a boring work, I can provide a patched Makefile to build them
| statically... Is it desirable?
Yes I believe this is desirable. I welcome the help you can offer with the
patched Makefile (I don't feel its boring work, but I'm not sure how to go
about doing it ;)
|
| >Also, you had mentioned that it might not be a good idea to upgrade the
| >old libcap on SLES-10 (see below) since Hawk Xu had seen a problem in
| >doing this. I'm still confused as to why I would even want to use the
| >new libcap, when using your tools displace it anyway?
|
| The first version of userspace tool (fscaps-1.0-kg.i386.rpm) didn't need
| to displace the original libcap, because it holds the facilities to
| interact with xattr subsystem (cap_file.c).
| 'cap_file.c' is originated at libcap suprisingly, but it is merely stub
| functions. So, I thought that integrating the libcap and 'cap_file.c' is
| natural way to provide userspace tools.
| >On Wed, Nov 15, 2006 at 09:08:55PM +0900, KaiGai Kohei wrote:
| >| Hi, Serge.
| >|
| >| Serge E. Hallyn wrote:
| >| >Quoting Bill O'Donnell ([EMAIL PROTECTED]):
| >| >>8102 execve("/sbin/setfcaps", ["setfcaps", "cap_net_raw=ep",
| >| >>"/bin/ping"], [/* 67 vars */]) = 0
| >| - snip -
| >| >>8102 capget(0x19980330, 0, {0, 0, 0}) = -1 EINVAL (Invalid argument)
| >| >
| >| >I don't see why this capget is returning -EINVAL. In fact I don't see
| >| >why it happens at all - cap_inode_setxattr would check
| >| >capable(CAP_SYS_ADMIN), but setxattr hasn't been called yet. Looking at
| >| >both libcap and setfcaps.c, I don't see where the capget comes from.
| >| >
| >| >As for the -EINVAL, kernel/capability.c:sys_capget() returns -EINVAL if
| >| >the _LINUX_CAPABILITY_VERSION is wrong - you have 0x19980330 which is
| >| >correct - if pid < 0 - but you send in 0 - or if security_capget
| >| >returns -EINVAL, which cap_capget (and dummy_capget) don't do.
| >| >
| >| >Kaigai, do you have any ideas?
| >|
| >| Bill said that he uses SLES10/ia64, so the version of libcap is different
| >| from Fedora Core's one. 'libcap-1.92-499.4.src.rpm' is bandled.
| >|
| >| Then, I found a strange code in libcap-1.92-499.4.src.rpm.
| >|
| >| The setfcaps calls cap_from_text() which is defined in libcap to parse
| >| the command line argument. It has the following function call chains:
| >|
| >| cap_from_text()
| >| -> cap_init()
| >| -> _libcap_establish_api()
| >|
| >| ---- the definition of _libcap_establish_api() ----
| >| void _libcap_establish_api(void)
| >| {
| >| struct __user_cap_header_struct ch;
| >| struct __user_cap_data_struct cs;
| >|
| >| if (_libcap_kernel_version) { <-- _libcap_kernel_version is 0
| >initially.
| >| _cap_debug("already identified kernal api 0x%.8x",
| >| _libcap_kernel_version);
| >| return;
| >| }
| >|
| >| memset(&ch, 0, sizeof(ch));
| >| memset(&cs, 0, sizeof(cs));
| >|
| >| (void) capget(&ch, &cs); <-- (?)
| >|
| >| switch (ch.version) {
| >|
| >| case 0x19980330:
| >| _libcap_kernel_version = 0x19980330;
| >| _libcap_kernel_features = CAP_FEATURE_PROC;
| >| break;
| >|
| >| case 0x19990414:
| >| _libcap_kernel_version = 0x19990414;
| >| _libcap_kernel_features = CAP_FEATURE_PROC|CAP_FEATURE_FILE;
| >| break;
| >|
| >| default:
| >| _libcap_kernel_version = 0x00000000;
| >| _libcap_kernel_features = 0x00000000;
| >| }
| >|
| >| _cap_debug("version: %x, features: %x\n",
| >| _libcap_kernel_version, _libcap_kernel_features);
| >| }
| >| ---------------------------------------------------
| >|
| >| capget() is called from _libcap_establish_api() with full-zeroed
| >| __user_cap_header_struct object at first time.
| >| The result of this, sys_capget() in kernel will return -EINVAL.
| >| (Why did strace say the first argument is 0x19980330?)
| >|
| >| Probably, Bill didn't update libcap.so.
| >|
| >| But I can't recommend Bill to update libcap immediately.
| >| As Hawk Xu said, it may cause a serious problem on the distro
| >| except Fedora Core 6. :(
| >|
| >| I have to recommend to use 'fscaps-1.0-kg.i386.rpm' now.
| >| It includes the implementation of interaction between application and
| >xattr.
| >| (Of couse, it's one of the features which should be provided by libcap.)
| >|
| >| Thanks,
| >| --
| >| Open Source Software Promotion Center, NEC
| >| KaiGai Kohei <[EMAIL PROTECTED]>
| >
|
|
| --
| KaiGai Kohei <[EMAIL PROTECTED]>
