All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Alexander Lochmann <alexander.lochmann@tu-dortmund.de>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jan Kara <jack@suse.cz>,
	Horst Schirmeier <horst.schirmeier@tu-dortmund.de>
Subject: Re: [PATCH] Fix sync. in blkdev_write_iter() acessing i_flags
Date: Sat, 8 Dec 2018 00:49:44 +0000	[thread overview]
Message-ID: <20181208004944.GA2217@ZenIV.linux.org.uk> (raw)
In-Reply-To: <5c86e85f-0ad4-935a-3021-7046551f361f@tu-dortmund.de>

On Fri, Dec 07, 2018 at 08:49:16PM +0100, Alexander Lochmann wrote:

> > _What_ SUID bit?  We are talking about a write to block device, for fsck sake...
> > 
> That's the way I understood Jan's explanation:
> "
> Thinking more about this I'm not sure if this is actually the right
> solution. Because for example the write(2) can set S_NOSEC flag wrongly
> when it would race with chmod adding SUID bit. So probably we rather need
> to acquire i_rwsem in blkdev_write_iter() if file does not have S_NOSEC set
> (we don't want to acquire it unconditionally as that would heavily impact
> scalability of block device writes).

	IDGI.  We are talking about a block device here.  What business could
file_remove_privs() have doing _anything_ to it?  should_remove_suid() returns
to return 0 for those; what case do you have in mind?  Somebody setting
security.capabilities on a block device inode?

	IMO the bug here is file_remove_privs() not buggering off immediately
after having observed that we are dealing with a block device.  It really
has nothing useful to do.

  reply	other threads:[~2018-12-08  0:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-07 16:10 [PATCH] Fix sync. in blkdev_write_iter() acessing i_flags Alexander Lochmann
2018-12-07 17:58 ` Al Viro
2018-12-07 19:49   ` Alexander Lochmann
2018-12-08  0:49     ` Al Viro [this message]
2018-12-10  9:47       ` Jan Kara
2018-12-14 10:55         ` [PATCH] Abort file_remove_privs() for non-reg. files Alexander Lochmann
2018-12-17  8:28           ` Jan Kara
2019-01-11 15:42             ` Alexander Lochmann
2019-03-08 15:10               ` Alexander Lochmann

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=20181208004944.GA2217@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=alexander.lochmann@tu-dortmund.de \
    --cc=horst.schirmeier@tu-dortmund.de \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@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.