lkml.org 
[lkml]   [1998]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: procfs pre-2.1.90-2 Oops, bug in proc_delete_dentry or proc_delete_inode or something , similar

On Fri, 13 Mar 1998, Andrea Arcangeli wrote:

> >It's easier than that:
> >
> > rm -rf /proc
> >
> >does the trick just fine :-)
>
> With the difference that this can be run only by root. loading/unloading a
> module can be done by kmod as well and an user can walk on /proc in the
> meantime.

True, although the former still surely has to come under the category of
"2.2 showstopper" since the system is in (little) pieces after that
command.

Also, I'm _highly_ unimpressed with the line in /proc,

inode->i_nlink = 0

or similar. It has the effect that if an in-core inode is modified during
its existance, it is possible for the changes to this inode to be dropped
on the floor without ever hitting the write_inode call-back. I think this
is conceptually _very_ poor even if the underlying filesystem is a
pseudo-one.

Or to summarise, I think we should be able to state "if an inode is
changed during its lifetime in-core, we guarantee the write_inode callback
is called. This write_inode routine may of course silently discard the
changes".

The reason I am whinging is that the i_nlink = 0 broken behaviour makes it
very difficult to implement my "process privacy" patch, (chmod og-rwx
/proc/<pid>, etc), and many people have been whining to me about getting
it in the kernel :)

Finally note that by holding open a fd to a /proc/<pid> directory in
2.1.recent, I can arbitrarily hide my processes as is it. Bad, bad, bad
(tm).

Chris


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

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