lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <15607.1494322345@warthog.procyon.org.uk>
Date:   Tue, 09 May 2017 10:32:25 +0100
From:   David Howells <dhowells@...hat.com>
To:     Miklos Szeredi <mszeredi@...hat.com>
Cc:     dhowells@...hat.com, viro <viro@...iv.linux.org.uk>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-nfs@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/9] VFS: Introduce a mount context

Miklos Szeredi <mszeredi@...hat.com> wrote:

> Forget remount, it's a historical remnant.

I don't think it can't be set aside so lightly.  Within the kernel, the option
parsing should share as much code as possible between new superblock config,
old new mount and old remount.

The 'trickiest' function we need to support is MS_RDONLY flipping.  That one
affects both the mount and the superblock.  I think all the rest only affect
one side or the other.

Given that a superblock can be mounted in multiple places, do we need to count
the number of read-only mounts that are holding a particular superblock and
only flip the superblock when they're all read-only?

Or do you advocate replacing "mount -o remount,[ro|rw]" with a pair of
operations - one to flip the mount and the other to flip the superblock?

Further, "emergency remount r/o" needs to be supported - though it might make
sense to add a special op just for that.

David

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ