fedora 9 help with unknown symbols in kernel -- cap_capget cap_capset_set
Skunk Worx
skunkworx at verizon.net
Tue Jun 17 05:06:57 UTC 2008
Skunk Worx wrote:
> stan wrote:
>> Skunk Worx wrote:
>>> stan wrote:
>>>> Skunk Worx wrote:
>>>>> Hello,
>>>>>
>>>>> I asked over on 'users' a few days ago and no help yet. I hope you
>>>>> don't mind my repeating the question here.
>>>>>
>>>>> We're a small company using some altera-based boards and our own
>>>>> driver to control them.
>>>>>
>>>>> Fedora 7 was working well, but we are getting some unknown symbols
>>>>> while evaluating an upgrade to F9.
>>>>>
>>>>> Any help, comments, suggestions are greatly appreciated.
>>>>>
>>>>> ---
>>>>> John
>>>>>
>>>>> code and issues :
>>>>>
>>>>> struct sched_param param = {70};
>>>>> kernel_cap_t effective, inheritable, permitted, all;
>>>>>
>>>>> cap_set_full(all); // be sure we have enough permissions to call
>>>>> // sched_setscheduler.
>>>>> // probably only need CAP_SYS_NICE, but let's be
>>>>> // "(un)safe"
>>>>>
>>>>>
>>>>> // save old permissions
>>>>> cap_capget(current,&effective, &inheritable, &permitted);
>>>>>
>>>>> // setup permissions to do this
>>>>> cap_capset_set(current,&all, &all, &all);
>>>>>
>>>>> // setup realtime priority
>>>>> ret=sched_setscheduler(current,SCHED_RR,¶m);
>>>>>
>>>>> // restore permissions
>>>>> cap_capset_set(current,&effective, &inheritable, &permitted);
>>>>>
>>>>>
>>>>> used to be able to do this in f7 / 2.6.23 kernel, now we get:
>>>>>
>>>>> WARNING: "cap_capset_set" [/usr/CSM/src/ONI/oni_driver/oni.ko]
>>>>> undefined!
>>>>> WARNING: "cap_capget" [/usr/CSM/src/ONI/oni_driver/oni.ko] undefined!
>>>>>
>>>>> when building and of course:
>>>>>
>>>>> oni: Unknown symbol cap_capget
>>>>> oni: Unknown symbol cap_capset_set
>>>>>
>>>>> when insmod'ing under f9 / 2.6.25
>>>>>
>>>> Now if you are writing drivers you are sophisticated users. I would
>>>> think you have already tried these, but just in case.
>>>>
>>>
>>> We write our own driver, there is no "oni.ko" in Fedora...we add it.
>>>
>> I misunderstood. I thought you were linking a kernel module and it
>> wasn't finding symbols.
>>
>> [snip]
>>> We've searched for the POSIX cap_* functions, and from what we can
>>> tell they should be exported, but for some reason no longer appear to
>>> be. I am not sure if this is the right language to explain the
>>> problem, but we can't seem to get to the symbols any more.
>>>
>>>
>> I think you are saying that they are no longer in a header file.
>
> I'm looking at the source code for the two kernels now.
>
> 2.6.23:
> -------
> extern int cap_capget (struct task_struct *target, kernel_cap_t
> *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted);
> ./linux-2.6.23/include/linux/security.h
>
> and
>
> int cap_capget (struct task_struct *target, kernel_cap_t *effective,
> EXPORT_SYMBOL(cap_capget);
> ./linux-2.6.23/security/commoncap.c
>
>
> 2.6.25:
> -------
> extern int cap_capget (struct task_struct *target, kernel_cap_t
> *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted);
> ./linux-2.6.25/include/linux/security.h
>
> and
>
> int cap_capget (struct task_struct *target, kernel_cap_t *effective,
> ./linux-2.6.25/security/commoncap.c
>
> ...so someone took out a group of EXPORT_SYMBOLS :
>
> EXPORT_SYMBOL(cap_capable);
> EXPORT_SYMBOL(cap_settime);
> EXPORT_SYMBOL(cap_ptrace);
> EXPORT_SYMBOL(cap_capget);
> EXPORT_SYMBOL(cap_capset_check);
> EXPORT_SYMBOL(cap_capset_set);
> EXPORT_SYMBOL(cap_bprm_set_security);
> EXPORT_SYMBOL(cap_bprm_apply_creds);
> EXPORT_SYMBOL(cap_bprm_secureexec);
> EXPORT_SYMBOL(cap_inode_setxattr);
> EXPORT_SYMBOL(cap_inode_removexattr);
> EXPORT_SYMBOL(cap_task_post_setuid);
> EXPORT_SYMBOL(cap_task_reparent_to_init);
> EXPORT_SYMBOL(cap_syslog);
> EXPORT_SYMBOL(cap_vm_enough_memory);
>
> This seems relevant :
>
> http://lists.openwall.net/linux-kernel/2007/08/14/418
>
> ...esp. the statement : "- remove a bunch of no longer used exports"
>
> Sounds like people can't use the POSIX capability API to set things like
> CAP_SYS_NICE in their drivers any more, or maybe there is a new way to
> do such things.
>
> At least one of our ring nodes (sometimes more) need to adjust the
> scheduler to keep up with the incoming data.
>
> ---
> John
>
...I think I found it :
http://lwn.net/Articles/211207/
http://www.friedhoff.org/posixfilecaps.html
Very cool...I am looking forward to trying this.
---
John
More information about the fedora-test-list
mailing list