lkml.org 
[lkml]   [2008]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.25 Kernel - Problems with capabilities
    Quoting David (david@unsolicited.net):
    > serge@hallyn.com wrote:
    >> Quoting David (david@unsolicited.net):
    >>
    >>> serge@hallyn.com wrote:
    >>>
    >>>>> /lib/libcap.so.1 -> libcap.so.1.92
    >>>>>
    >>>>> I guess that's 1.92 (should be the version shipped with SuSE 9.1).
    >>>>>
    >>>> Ok, thanks, then it's definately not what I was thinking.
    >>>>
    >>>> (Will wait to check out your strace)
    >>>>
    >>> strace attached.
    >>>
    >>> Cheers
    >>> David
    >>>
    >>>
    >>
    >> ...
    >>
    >>> capget(0x20071026, 0, {, , }) = -1 EINVAL (Invalid argument)
    >>>
    >>
    >> This is odd. libcap-1.x should be passing in 0x19980330.
    >>
    >> Next, given the -EINVAL return value ntpd should be seeing a NULL result
    >> from cap_get_proc() and exiting right there.
    >>
    >> What version of ntpd is this? (I must be looking at a wrong value, but
    >> even so the fact that cap_get_proc()->capget() is using 0x20071026 for
    >> version doesn't make sense)
    >>
    >>
    >>> capset(0, 0, {CAP_NET_BIND_SERVICE|CAP_SYS_TIME,
    >>> CAP_NET_BIND_SERVICE|CAP_SYS_TIME, CAP_NET_BIND_SERVICE|CAP_SYS_TIME}) =
    >>> -1 EINVAL (Invalid argument)
    >>> time(NULL) = 1208803493
    >>> write(5, "21 Apr 19:44:53 ntpd[6118]: cap_"..., 92) = 92
    >>> munmap(0x40022000, 4096) = 0
    >>> exit_group(-1) = ?
    >>> Process 6118 detached
    >>>
    >>
    >>
    > Oh dear .. more investigation... here's the source from libcap-1.92.
    > capget() is being called with null arguments, which I guess returns with
    > the latest version in ch.version ?
    >
    > The switch then fails and the set gets called with version = 0 ??
    >
    > Cheers
    > David
    >
    > void _libcap_establish_api(void)
    > {
    > struct __user_cap_header_struct ch;
    > struct __user_cap_data_struct cs;
    >
    > if (_libcap_kernel_version) {
    > _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);
    > }

    Interesting. The version I was looking at (1.10) has nothing like this.

    I don't know what shipped with recent RedHat and Fedora distros, but I
    guess based on this we can in fact expect more failures from at least
    SuSe distros.

    We can't reasonably have newer kernels reply to a query with an older
    libcap version, so I don't know what to do here. Andrew, do you have
    any ideas?

    thanks,
    -serge


    \
     
     \ /
      Last update: 2008-04-22 04:49    [W:0.030 / U:0.860 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site