not sure why u need to read files in kernel. If it is parameters for
LKM, then u can use ioctl interface, or sysctl, or procfs
interface.
If u really insist on using the syscall sys_* API to access the files,
yes, that is possible. But "user permission" does not exists in
kernel space. The concept of user is at the userspace level, and so
is "permission". Ie,
/hdc1/download/2.6/linux-2.6/include/linux>objdump -t /lib/libc.so.6 |
grep -i access
000b0a00 l F .text 000000ef __euidaccess
000b09b0 l F .text 00000043 __access
000b09b0 l F .text 00000043 __GI___access
000b09b0 l F .text 00000043 __GI_access
000b0a00 w F .text 000000ef euidaccess
000b09b0 w F .text 00000043 access
000b0a00 w F .text 000000ef eaccess
000b0af0 g F .text 000002de faccessat
/hdc1/download/2.6/linux-2.6/include/linux>objdump -t /lib/libc.so.6 |
grep -i uid
000b8560 l F .text 0000007b __setreuid
0008aca0 l F .text 0000020b __new_getpwuid_r
0008cea0 l F .text 0000005f __getresuid
0008cea0 l F .text 0000005f .hidden __GI___getresuid
0008cb20 l F .text 00000011 __geteuid
000b0a00 l F .text 000000ef __euidaccess
0008aca0 l F .text 0000020b __getpwuid_r
000b8660 l F .text 000000aa .hidden __GI_seteuid
0008cbd0 l F .text 0000006c __setuid
000f6e00 l F .text 0000005f __old_getpwuid_r
000ecee0 l F .text 00000072 __nscd_getpwuid_r
0008cf60 l F .text 00000087 __setresuid
0008cb00 l F .text 00000011 __getuid
0008cf60 l F .text 00000087 .hidden __GI___setresuid
000b0a00 w F .text 000000ef euidaccess
000f6e00 g F .text 0000005f [EMAIL PROTECTED]
000b8560 w F .text 0000007b setreuid
000bf510 g F .text 00000018 setfsuid
0008cea0 w F .text 0000005f getresuid
0008a660 g F .text 00000134 getpwuid
0008cbd0 w F .text 0000006c setuid
0008cf60 w F .text 00000087 setresuid
0008cb00 w F .text 00000011 getuid
000b8660 g F .text 000000aa seteuid
0008aca0 g F .text 0000020b getpwuid_r@@GLIBC_2.1.2
0008cb20 w F .text 00000011 geteuid
And then "man access" to see details.
The /lib/libc.so.6 is the userspace implementation checking before it
jump to kernelspace.
Sure, sys_faccessat( kernelspace API for userspace access* family of
API), can check uid permission:
asmlinkage long sys_faccessat(int dfd, const char __user *filename,
int mode)
{
struct path path;
struct inode *inode;
int old_fsuid, old_fsgid;
kernel_cap_t uninitialized_var(old_cap); /* !
SECURE_NO_SETUID_FIXUP */
int res;
if (mode & ~S_IRWXO) /* where's F_OK, X_OK, W_OK, R_OK? */
return -EINVAL;
old_fsuid = current->fsuid;
old_fsgid = current->fsgid;
current->fsuid = current->uid;
current->fsgid = current->gid;
So now your LKM must simulate the operation of sys_open() +
sys_access() + sys_close() + spinlock handling (to cater for SMP
scenario etc) or semaphore/mutex locks etc. It is always possible,
but at the costs of x10 the complexities.....
lir 写道：
> Hey,
>
> I was pondering about performing file operations from inside the
> kernel.
> Say we talk about a driver that is compiled within the kernel or an
> LKM which is loadable - it is possible
> to perform file operations such as open, read and write from inside
> the kernel using the provided sys_* functions
> such as sys_open and the rest.
>
> My question is, how is it possible to specify to the open syscall upon
> which user permissions to use?
> If you investigate the sys_open function you'll see that at some point
> (allocation) it uses the current pointer
> to grab the uid and gid upon which to check for permissions.
>
> How is this a problem?
> Well if the sys_open is called from a user process then that's normal
> because the user process has been
> interrupted and THAT process will be what the current pointer address
> to, but if we're doing it all in kernel
> then the current point will be of some random process which we have no
> affiliation with...
>
> So, what do you think? is it possible to explicitly provide a
> task_struct of a dummy process which I created
> on my own to functions like sys_open?
>
>
> Regards,
> Liran.
