Hello gregkh,

Could you please also backport the commit d759bfa4e7919b89357de50a2e23817079889195 and e729eac6f65e11c5f03b09adcc84bd5bcb230467 to the linux-stable? Since these two commits solved the similar problem for udffs as this one for isofs.

Regards,
Hui.

On 09/25/2013 07:18 AM, [email protected] wrote:
This is a note to let you know that I've just added the patch titled

     isofs: Refuse RW mount of the filesystem instead of making it RO

to the 3.4-stable tree which can be found at:
     
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
      isofs-refuse-rw-mount-of-the-filesystem-instead-of-making-it-ro.patch
and it can be found in the queue-3.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.


>From 17b7f7cf58926844e1dd40f5eb5348d481deca6a Mon Sep 17 00:00:00 2001
From: Jan Kara <[email protected]>
Date: Thu, 25 Jul 2013 11:49:11 +0200
Subject: isofs: Refuse RW mount of the filesystem instead of making it RO

From: Jan Kara <[email protected]>

commit 17b7f7cf58926844e1dd40f5eb5348d481deca6a upstream.

Refuse RW mount of isofs filesystem. So far we just silently changed it
to RO mount but when the media is writeable, block layer won't notice
this change and thus will think device is used RW and will block eject
button of the drive. That is unexpected by users because for
non-writeable media eject button works just fine.

Userspace mount(8) command handles this just fine and retries mounting
with MS_RDONLY set so userspace shouldn't see any regression.  Plus any
tool mounting isofs is likely confronted with the case of read-only
media where block layer already refuses to mount the filesystem without
MS_RDONLY set so our behavior shouldn't be anything new for it.

Reported-by: Hui Wang <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
  fs/isofs/inode.c |   16 +++++-----------
  1 file changed, 5 insertions(+), 11 deletions(-)

--- a/fs/isofs/inode.c
+++ b/fs/isofs/inode.c
@@ -119,8 +119,8 @@ static void destroy_inodecache(void)
static int isofs_remount(struct super_block *sb, int *flags, char *data)
  {
-       /* we probably want a lot more here */
-       *flags |= MS_RDONLY;
+       if (!(*flags & MS_RDONLY))
+               return -EROFS;
        return 0;
  }
@@ -769,15 +769,6 @@ root_found:
         */
        s->s_maxbytes = 0x80000000000LL;
- /*
-        * The CDROM is read-only, has no nodes (devices) on it, and since
-        * all of the files appear to be owned by root, we really do not want
-        * to allow suid.  (suid or devices will not show up unless we have
-        * Rock Ridge extensions)
-        */
-
-       s->s_flags |= MS_RDONLY /* | MS_NODEV | MS_NOSUID */;
-
        /* Set this for reference. Its not currently used except on write
           which we don't have .. */
@@ -1536,6 +1527,9 @@ struct inode *isofs_iget(struct super_bl
  static struct dentry *isofs_mount(struct file_system_type *fs_type,
        int flags, const char *dev_name, void *data)
  {
+       /* We don't support read-write mounts */
+       if (!(flags & MS_RDONLY))
+               return ERR_PTR(-EACCES);
        return mount_bdev(fs_type, flags, dev_name, data, isofs_fill_super);
  }

Patches currently in stable-queue which might be from [email protected] are

queue-3.4/isofs-refuse-rw-mount-of-the-filesystem-instead-of-making-it-ro.patch


--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to