lkml.org 
[lkml]   [2004]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: file as a directory
>> >> [quote]
>> >[and another one]
>>
>> Do you really want to put an XML parser and all the associated code
>> (read: McDonalds*) into the kernel?
>
>AND assume the XML file is correct...

AND use newer compilers that supposedly create bigger code.

(I do not say that they do, and I neither say that they do not, I just read
about the backwards compat on kerneltraffic.)

Clearly, this is either a userspace job (-> FUSE, hint, hint) or nothing at
all. What if this madness was applied to any file{,-type} in the FS? You could
open() something and always got a shot (i.e. open(...) = ESUCCESS).

Having something like /etc/passwd/daemon spitting out the GECOS for user
"daemon" would make systems more open for stack smash attacks. Instead of
trying to squash a lot of shellcode just to read <your favorite file>, you just
need to use <your favorite file>/<your favorite entry> and *poof*. Even worse
when it's done with O_RDWR / O_WRONLY.

Hell, I do not even want to imagine

unlink("unlinkthisfile");
if(stat("unlinkthisfile", &sb) == 0) {
BUG(); <--
}

"<--" coming true just because that's the logic of some extension module.


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

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