[<prev] [next>] [day] [month] [year] [list]
Message-ID: <34746.192.168.1.70.1206487767.squirrel@neil.brown.name>
Date: Wed, 26 Mar 2008 10:29:27 +1100 (EST)
From: "NeilBrown" <neilb@...e.de>
To: "Al Viro" <viro@...IV.linux.org.uk>
Cc: "Tetsuo Handa" <penguin-kernel@...ove.sakura.ne.jp>,
miklos@...redi.hu, haveblue@...ibm.com,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
akpm@...ux-foundation.org, hch@...radead.org,
linux-security-module@...r.kernel.org, jmorris@...ei.org
Subject: Re: r-o bind in nfsd
On Wed, March 26, 2008 9:49 am, Al Viro wrote:
> On Wed, Mar 26, 2008 at 09:32:08AM +1100, NeilBrown wrote:
>
>> > (1) The kernel don't know what operation (open/create/truncate etc.)
>> > will be
>> > done at the moment of link_path_walk().
>>
>> Though the 'indent' data structure could be used to carry this
>> information.
>
> If it's 'intent',
Yes, sorry.
> that mess will be gone next cycle.
Cool. Any chance of a preview? Is it in -next or -mm ??
>> > (3) The rename() and link() operations handle two pathnames.
>> > But, it is not possible to know both pathnames at the moment of
>> > link_path_walk().
>>
>> Not an insolvable problem.
>> One could imagine an implementation where a TYPE_RENAME_FROM security
>> check produced a cookie that was consumed by a TYPE_RENAME_TO security
>> check. The cookie could then be used by the security module to
>> make any connection between the two names that might be appropriate.
>
> alt.tasteless.software is that -> way...
>
While I have no desire to defend that particular design, saying "tasteless"
without suggesting an alternate approach does appear somewhat unhelpful.
NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists