linux-ext4 - [Bug 202485] chmod'ed permission not persisted upon fsync

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]

Date:   Sat, 02 Feb 2019 03:38:30 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...r.kernel.org
Subject: [Bug 202485] chmod'ed permission not persisted upon fsync

https://bugzilla.kernel.org/show_bug.cgi?id=202485

Theodore Tso (tytso@....edu) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tytso@....edu

--- Comment #1 from Theodore Tso (tytso@....edu) ---
This is going to be true of all special files (block and character devices,
unix domain sockets, FIFO's etc.), and it's going to be true for all file
systems in Linux.

That's because the VFS provides the file_operations structures for these
special files, and the underlying file system never gets the notified about the
fsync().   All of these special files don't have a fsync function defined, so
fsync() on these devices will be a no-op.

Whether or not this is a bug is an interesting philosophical question.   The
Single Unix Specification is extremely non-directive on this score, saying that
it's all implementation defined.   The Linux man page does have this statement:

        As well as flushing the file data, fsync() also flushes the metadata
        information associated with the file (see inode(7)).

So what has been implemented in the Linux kernel for decades is at odds with
this statement, at least as it relates to special Unix files.

Do you have a use case or a program where this is important?  Or is this
something merely of academic interest?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.