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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjz+y82U8ycSBfey_ov1GxdiUkkVpjJA1f0=JogWqUp2w@mail.gmail.com>
Date:   Fri, 24 Nov 2023 10:39:51 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     David Howells <dhowells@...hat.com>
Cc:     Marc Dionne <marc.dionne@...istor.com>,
        linux-afs@...ts.infradead.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] afs: Miscellaneous fixes

On Fri, 24 Nov 2023 at 07:52, David Howells <dhowells@...hat.com> wrote:
> Btw, I did want to ask about (5): Does a superblock being marked SB_RDONLY
> imply immutability to the application?

Obviously not - any network filesystem can and will change from under
you, even if the local copy is read-only.

So SB_RDONLY can only mean that writes to that instance of the
filesystem will fail.

It's a bit stronger than MNT_READONLY, in that for a *local*
filesystem, SB_RDONLY tends to mean that it's truly immutable (while
MNT_READONLY is obviously per mount) but even then some sub-mount
thing (and I guess the AFS snapshot is a good example of that) might
expose the same filesystem through multiple superblocks.

Exactly like a network filesystem inevitably will.

In any case, any user space that thinks SB_RDONLY is some kind of
immutability signal is clearly buggy. At a minimum, such user space
would have to limit itself to particular filesystem types and say "I
know _this_ filesystem can have only one superblock"). And I'd argue
that while that might work in practice, it's insane.

                Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ