[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110902163711.GA3124@albatros>
Date: Fri, 2 Sep 2011 20:37:11 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: Cyrill Gorcunov <gorcunov@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>
Cc: "Kirill A. Shutemov" <kirill@...temov.name>, containers@...ts.osdl.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
Nathan Lynch <ntl@...ox.com>, kernel-hardening@...ts.openwall.com,
Oren Laadan <orenl@...columbia.edu>,
Daniel Lezcano <dlezcano@...ibm.com>,
Glauber Costa <glommer@...allels.com>,
James Bottomley <jbottomley@...allels.com>,
Tejun Heo <tj@...nel.org>, Alexey Dobriyan <adobriyan@...il.com>,
Al Viro <viro@...IV.linux.org.uk>,
Pavel Emelyanov <xemul@...allels.com>
Subject: Re: [patch 2/2] fs, proc: Introduce the /proc/<pid>/map_files/
directory v6
Hi,
On Thu, Sep 01, 2011 at 12:05 +0400, Cyrill Gorcunov wrote:
> ...
> > > +/*
> > > + * NOTE: The getattr/setattr for both /proc/$pid/map_files and
> > > + * /proc/$pid/fd seems to have share the code, so need to be
> > > + * unified and code duplication eliminated!
> >
> > Why not do this now?
>
> There are a couple of reasons. Yesterday I was talking to
> Vasiliy Kulikov about this snippet, so he seems about to send
> you patches related to /proc/$pid/fd update, and after those
> patches will be merged we are to drop code duplication.
> Vasiliy, what the status of the update?
It looks like protecting directories with sensible contents is a nasty
thing. The problem here is that if the dentry is present in the cache,
->lookup() is not called at all and the permissions can be checked in
fop/dop/iop specific handler (getattr(), readlink(), etc.). However, it
would be much simplier to hook ->lookup() only. Otherwise, we have to
define procfs handlers for all operations, which don't call
->d_revalidate().
Is it possible to disable caching dentry for specific files? It is not
performace critical thing in fd and map_files and it would much simplify
the task. Creating handlers for all these op handler bloats procfs.
Also I'm not sure what other handlers might reveal dentry presence.
Besides ->getattr() I could find only one thing - ->link() (Cyrill,
AFAICS ->setattr() doesn't reveal files' presence). Someone more
familiar with vfs than me - please, help to identify all infoleak
sources!
Thank you,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
