From: Al Viro <viro@ZenIV.linux.org.uk>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [patch resend] vfs: move executable checking into ->permission()
Date: Thu, 31 Jul 2008 01:33:32 +0100 [thread overview]
Message-ID: <20080731003332.GJ28946@ZenIV.linux.org.uk> (raw)
In-Reply-To: <E1KOBJb-0005L0-RF@pomaz-ex.szeredi.hu>
On Wed, Jul 30, 2008 at 03:02:03PM +0200, Miklos Szeredi wrote:
> static int coda_ioctl_permission(struct inode *inode, int mask)
> {
> - return 0;
> + return check_execute(dentry->d_inode, mask);
> }
Er?
a) mismerge from dentry-based variant
b) I'd say return mask & MAY_EXEC ? -EACCES : 0 - it's *NOT* going to
be an executable file, TYVM.
> static int hfs_permission(struct inode *inode, int mask)
> {
> if (S_ISREG(inode->i_mode) && mask & MAY_EXEC)
> - return 0;
> + return check_execute(inode, mask);
> return generic_permission(inode, mask, NULL);
> }
WTF is going on in that one? I realize that you are not changing behaviour,
but...
> +int check_execute(struct inode *inode, int mask)
> +{
> + if ((mask & MAY_EXEC) && S_ISREG(inode->i_mode) &&
> + !(inode->i_mode & S_IXUGO))
> + return -EACCES;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(check_execute);
Umm... I'm not sure. For one thing, I'd take check for MAY_EXEC to callers.
For another, quite a few of those might have enough information to make calling
that helper pointless.
> +++ linux-2.6/fs/proc/proc_sysctl.c 2008-07-30 14:39:31.000000000 +0200
> @@ -311,6 +311,9 @@ static int proc_sys_permission(struct in
> error = sysctl_perm(head->root, table, mask);
>
> sysctl_head_finish(head);
> + if (!error)
> + error = check_execute(inode, mask);
> +
> return error;
> }
No. If anything, we want non-directories fail MAY_EXEC here, no matter
what i_mode we might have. Executable files in /proc/sys/* are NOT going
to be allowed, no matter what...
> if (mask & ~mode & (MAY_READ | MAY_WRITE | MAY_EXEC))
> - error = -EACCES;
> - return error;
> + return -EACCES;
> +
> + return check_execute(inode, mask);
That's wrong. If mask contains MAY_EXEC and we got to calling check_execute(),
we know that ~mode & MAY_EXEC is 0. IOW, we know that inode->i_mode >> 6 has
bit 0 set. IOW, we know that inode->i_mode contain S_IXUSR. IOW, your
check_execute() here is an obfuscated way to spell 0.
next prev parent reply other threads:[~2008-07-31 0:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-30 13:02 [patch resend] vfs: move executable checking into ->permission() Miklos Szeredi
2008-07-31 0:33 ` Al Viro [this message]
2008-07-31 11:41 ` Miklos Szeredi
2008-07-31 16:10 ` Al Viro
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=20080731003332.GJ28946@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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.