From: Goffredo Baroncelli <kreijack@inwind.it>
To: David Sterba <dsterba@suse.cz>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: make root id query unprivileged
Date: Wed, 13 May 2015 18:41:54 +0200 [thread overview]
Message-ID: <55537ED2.2050801@inwind.it> (raw)
In-Reply-To: <1431450889-27968-1-git-send-email-dsterba@suse.cz>
Hi David,
On 2015-05-12 19:14, David Sterba wrote:
> The INO_LOOKUP ioctl can lookup path for a given inode number and is
> thus restricted. As a sideefect it can find the root id of the
> containing subvolume and we're using this int the 'btrfs inspect rootid'
> command.
>
> The restriction is unnecessary in case we set the ioctl args
> args::treeid = 0
> args::objectid = 256 (BTRFS_FIRST_FREE_OBJECTID)
>
> Then the path will be empty and the treeid is filled with the root id of
> the inode on which the ioctl is called. This behaviour is unchanged,
> after the root restriction is removed.
I think that make sense to add another ioctl instead of relaxing the privilege check
on the basis of the parameters.
If I read correctly the code, in this case the function
btrfs_search_path_in_tree() is not even called: it is requested to return only
BTRFS_I(inode)->root->root_key.objectid;
Goffredo
>
> Signed-off-by: David Sterba <dsterba@suse.cz>
> ---
>
> fs/btrfs/ioctl.c | 20 ++++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
> index 1c22c6518504..578ff63a9b74 100644
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -2271,10 +2271,7 @@ static noinline int btrfs_ioctl_ino_lookup(struct file *file,
> {
> struct btrfs_ioctl_ino_lookup_args *args;
> struct inode *inode;
> - int ret;
> -
> - if (!capable(CAP_SYS_ADMIN))
> - return -EPERM;
> + int ret = 0;
>
> args = memdup_user(argp, sizeof(*args));
> if (IS_ERR(args))
> @@ -2282,13 +2279,28 @@ static noinline int btrfs_ioctl_ino_lookup(struct file *file,
>
> inode = file_inode(file);
>
> + /*
> + * Unprivileged query to obtain the containing subvolume root id. The
> + * path is reset so it's consistent with btrfs_search_path_in_tree.
> + */
> if (args->treeid == 0)
> args->treeid = BTRFS_I(inode)->root->root_key.objectid;
>
> + if (args->objectid == BTRFS_FIRST_FREE_OBJECTID) {
> + args->name[0] = 0;
> + goto out;
> + }
> +
> + if (!capable(CAP_SYS_ADMIN)) {
> + ret = -EPERM;
> + goto out;
> + }
> +
> ret = btrfs_search_path_in_tree(BTRFS_I(inode)->root->fs_info,
> args->treeid, args->objectid,
> args->name);
>
> +out:
> if (ret == 0 && copy_to_user(argp, args, sizeof(*args)))
> ret = -EFAULT;
>
>
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
next prev parent reply other threads:[~2015-05-13 16:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-12 17:14 [PATCH] btrfs: make root id query unprivileged David Sterba
2015-05-13 16:41 ` Goffredo Baroncelli [this message]
2015-05-13 17:02 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55537ED2.2050801@inwind.it \
--to=kreijack@inwind.it \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.