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  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
Subject: [Bug 202485] chmod'ed permission not persisted upon fsync

Theodore Tso ( changed:

           What    |Removed                     |Added
                 CC|                            |

--- Comment #1 from Theodore Tso ( ---
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.

Powered by blists - more mailing lists