lkml.org 
[lkml]   [2000]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: generic_file_read access
From
Date
fober@grame.fr (Dominique Fober) writes:

> Some of the kernel exported symbols allows to acces files (open.c : filp_open, filp_close). However, the 'generic_file_read' function (filemap.c) seems to be restricted to buffers located in user space (access_ok macro)
> (which prevents it from being called by a kernel module).
> I would like to know the reason of this restriction which seems to be arbitrary as
> bypassing the check don't affect the function behavior.

Oh it does. Then you be able to read random kernel addresses from
every file system using generic_file_read, stealing other users data.

Now when you want to read a file from kernel space you usually have
a bug in the design. In Unix this should be near always be done by user space
not in the kernel (e.g. to load firmware you would write a small utility
that loads them into your driver using a special ioctl etc.). Usually
you do not want to deal with path names in kernel drivers, that's
bad style.

That being said, you can prevent the access_ok() check by using
mm_segment_t oldfs = get_fs();
set_fs(KERNEL_DS);
/* call */
set_fs(oldfs);

-Andi


--
This is like TV. I don't like TV.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.032 / U:0.784 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site