[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <14013.1274277009@jrobl>
Date: Wed, 19 May 2010 22:50:09 +0900
From: "J. R. Okajima" <hooanon05@...oo.co.jp>
To: "Aneesh Kumar K. V" <aneesh.kumar@...ux.vnet.ibm.com>
Cc: Dave Chinner <david@...morbit.com>, hch@...radead.org,
viro@...iv.linux.org.uk, adilger@....com, corbet@....net,
serue@...ibm.com, neilb@...e.de, linux-fsdevel@...r.kernel.org,
sfrench@...ibm.com, philippe.deniel@....FR,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH -V8 2/9] vfs: Add name to file handle conversion support
"Aneesh Kumar K. V":
> How about the below patch ?
>
> commit 5f421ffbe9dd7bb84c5992b1725c06b511bc76d8
> Author: Aneesh Kumar K.V <aneesh.kumar@...ux.vnet.ibm.com>
> Date: Wed May 19 14:52:44 2010 +0530
>
> vfs: Return ENOSYS if CONFIG_EXPORTFS is not enabled
Of course, I have no objection. :-)
Let me make sure some other issues.
If a malicious user passes altered dirfd or handle parameters, then
these things may happen.
- opens another file.
But it should not be a security hole, because finish_open_handle()
calls may_open() and the permission bits are tested expectedly.
- kernel crashes.
If s_export_op->fh_to_dentry() expects the passed handle is always
correct, then it may crash. But this is a problem of FS, instead of
open_by_handle().
- returns an error.
It is a matter of the application.
Right?
And the decode routine may return an anonymous (disconnected) dentry.
In this case, if LSM detects something wrong and produces a message,
then the filename will not be printed correctly.
This is not a problem of open_by_handle() either. Right?
J. R. Okajima
--
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