LinuxQuestions.org - How to enable linux filesystem capabilities for kernel 2.24.18

- Linux - General (https://www.linuxquestions.org/questions/linux-general-1/)

- - How to enable linux filesystem capabilities for kernel 2.24.18 (https://www.linuxquestions.org/questions/linux-general-1/how-to-enable-linux-filesystem-capabilities-for-kernel-2-24-18-a-219997/)

How to enable linux filesystem capabilities for kernel 2.24.18

I just wonder if anybody know how to enable the filesystem capabilities in RedHat Linux 8.0 (Kernel 2.24.18) ? To be more specific, I would like to be able to raise the capabilities of any non root-owned executable files to perform some specific task such as mlock.

I have tried the kernel patch from ¡§Olaf Dietsche¡¨ but it seems that his patch is only for kernel 2.24.3.

Any suggestion or hint would be very appreciated.

Thanks in advance,

-=Toubo=-

I think that's a 2.4.18 kernel maybe? But I'm not sure what you are trying to do?

Is it not possible to upgrade your kernel to 2.24.3, then? Or even to the 2.4 series, which might have this capability inbuilt?

There is no kernel 2.24.18 or 2.24.3? RH8 came with 2.4.18 apparently.

I don't know what you are trying to achieve really? I read some of the Olaf Dietsche stuff, but I guess what would be helpful to everyone would be if you said exactly what you wanted to do and what apps you wanted to run, but not as root, etc?

Yes, I got it that RH8 most likely came with 2.4.18 (maybe the extra "2" was a typo), but there are still a few RH8 repositories around somewhere, and I would imagine that those might well contain a few kernel upgrades from the time that RH8 was current.

I don't know anything about this either, but given the definition of mlock

Quote:

NAME

mlock, munlock - lock or unlock a range of process address space (REALTIME)

SYNOPSIS

#include <sys/mman.h>

int mlock(const void * addr, size_t len);
int munlock(const void * addr, size_t len);

DESCRIPTION

The function mlock() causes those whole pages containing any part of the address space of the process starting at address addr and continuing for len bytes to be memory resident until unlocked or until the process exits or execs another process image. The implementation may require that addr be a multiple of {PAGESIZE}.

The function munlock() unlocks those whole pages containing any part of the address space of the process starting at address addr and continuing for len bytes, regardless of how many times mlock() has been called by the process for any of the pages in the specified range. The implementation may require that addr be a multiple of the {PAGESIZE}.

If any of the pages in the range specified to a call to munlock() are also mapped into the address spaces of other processes, any locks established on those pages by another process are unaffected by the call of this process to munlock(). If any of the pages in the range specified by a call to munlock() are also mapped into other portions of the address space of the calling process outside the range specified, any locks established on those pages via the other mappings are also unaffected by this call.

Upon successful return from mlock(), pages in the specified range will be locked and memory resident. Upon successful return from munlock(), pages in the specified range will be unlocked with respect to the address space of the process. Memory residency of unlocked pages is unspecified.

The appropriate privilege is required to lock process memory with mlock().

it would appear that it's a question of attempting to increase functionality of the kernel, without upgrading it to the point of possible breakage.

Although admittedly, if I needed this functionality for some reason, I'd be giving serious thought to upgrading from RH8. But maybe that's impossible at this time, or for this box (maybe it's a server).

Sorry, it's late here and at a glance I thought your 'motub' tag looked a lot like 'toubo' tag... Well it has most of the same letters :)

I didn't look hard and thought you were the original guy :)

I was just trying to figure what he was trying to achieve and see if there was some other simple way arround it.

Sorry for the confusion, it's indeed a typo. The kernel that I am in trouble with is 2.4.18. Since "Olaf Dietsche"'s filesystem capabilities kernel patch is only for 2.4.3, it fails to patch a much newer version of kernel. I can't change the version of kernel for now since there are some hardware driver that requires this version of kernel.

What I am trying to achieve here is to be able to give my application a special privilege (capabilities) so that it can be ran by anybody (as a non-root own process) while having the capabilities such as mlock() and sched_setscheduler(). I have tried the sudo command but it really made the process ran as root and the files generated by my application became root own as well. This is not desire since the user who ran the application can no longer manipulate the generated files.

At mean time, I have patched the kernel to enable the "CAP_SETPCAP" capability and I have created a root-own process that give capabilities to another process upon the request. Again, this is not desire since it requires every single application that needs special capability to be patched. It's still much preferable if the kernel can recognize the capabilities that a root user set to an application, and enable these capabilities for the application's process regardless of who ran the application.

Hi Motub,

Based on what you said:
"Although admittedly, if I needed this functionality for some reason, I'd be giving serious thought to upgrading from RH8..."

Are you suggesting that a newer version of RedHat Linux or Kernel will have the filesystem capabilities ??? I thought that it's still debatable and I heard that this capabilities won't be put in kernel 2.6 as well. Please correct me if I am wrong.

In addition, I have tried to set the s bit (chmod a+s app_name) but the application still won't have enough privilege to use the mlock().