From: Ingo Molnar <mingo@elte.hu>
To: Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Marcin Slusarz <marcin.slusarz@gmail.com>,
linux-kernel@vger.kernel.org, Randy Dunlap <rdunlap@xenotime.net>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org,
kernel-hardening@lists.openwall.com
Subject: Re: [PATCH] fs: hardlink creation restriction cleanup
Date: Wed, 22 Feb 2012 11:23:01 +0100 [thread overview]
Message-ID: <20120222102301.GC30339@elte.hu> (raw)
In-Reply-To: <20120222012103.GA13295@www.outflux.net>
* Kees Cook <keescook@chromium.org> wrote:
> Clean-up of hardlink restriction logic, as suggested by Andrew Morton.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> fs/namei.c | 59 +++++++++++++++++++++++++++++++++++++++++------------------
> 1 files changed, 41 insertions(+), 18 deletions(-)
>
> diff --git a/fs/namei.c b/fs/namei.c
> index 8ed4e00..a4a21a5 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -693,46 +693,69 @@ static inline int may_follow_link(struct path *link)
> }
>
> /**
> + * safe_hardlink_source - Check for safe hardlink conditions
> + * @inode: the source inode to hardlink from
> + *
> + * Return false if at least one of the following conditions:
> + * - inode is not a regular file
> + * - inode is setuid
> + * - inode is setgid and group-exec
> + * - access failure for read and write
> + *
> + * Otherwise returns true.
> + */
> +static bool safe_hardlink_source(struct inode *inode)
> +{
> + mode_t mode = inode->i_mode;
> +
> + /* Special files should not get pinned to the filesystem. */
> + if (!S_ISREG(mode))
> + return false;
> + /* Setuid files should not get pinned to the filesystem. */
> + if (mode & S_ISUID)
> + return false;
> + /* Executable setgid files should not get pinned to the filesystem. */
> + if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP))
> + return false;
> + /* Hardlinking to unreadable or unwritable sources is dangerous. */
> + if (inode_permission(inode, MAY_READ | MAY_WRITE))
> + return false;
> +
> + return true;
A really minor nitpick, could we use this form please:
static bool safe_hardlink_source(struct inode *inode)
{
mode_t mode = inode->i_mode;
/* Special files should not get pinned to the filesystem. */
if (!S_ISREG(mode))
return false;
/* Setuid files should not get pinned to the filesystem. */
if (mode & S_ISUID)
return false;
/* Executable setgid files should not get pinned to the filesystem. */
if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP))
return false;
/* Hardlinking to unreadable or unwritable sources is dangerous. */
if (inode_permission(inode, MAY_READ | MAY_WRITE))
return false;
return true;
}
Those separate blocks of comments and conditions stand out much
nicer this way, making it way easier on the eyes - to my eyes at
least ;-)
Thanks,
Ingo
next prev parent reply other threads:[~2012-02-22 10:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-22 1:21 [PATCH] fs: hardlink creation restriction cleanup Kees Cook
2012-02-22 10:23 ` Ingo Molnar [this message]
2012-02-22 19:10 ` Kees Cook
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=20120222102301.GC30339@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcin.slusarz@gmail.com \
--cc=rdunlap@xenotime.net \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox