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] [day] [month] [year] [list]

Date:   Sat, 02 Feb 2019 14:29:50 +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

--- Comment #3 from Theodore Tso (tytso@....edu) ---
I do believe we should either fix the man page to document existing practice,
or change the kernel.   Changing kernel behaviour here going to be a fairly
involved, since today the filesystem layer (ext4, btrfs, xfs) is not even
informed when a special device file is open, read, written, fsync'ed, etc.  
Which makes sense; when you write to /dev/tty or /dev/ttyS1, or /dev/sda3,
etc., it has nothing to do with the file system where the where the directory
entry to said special device file is found.   And indeed, if one were to open
/dev/sda3, write to it, and then fsync it, the vast majority of user space
programs care about the *data* written to /dev/sda3, and not to any associated
metadata, such as the permission bits or the modtime of /dev/sda3 being
persisted.

The history behind fsync(2) was that it was intended for regular files, not
special device files, and for database programs in particular.  The
fdatasync(2) call was added later as an optimization to avoid unnecessary
updates to the inode when it was not necessary to be able to access the data
blocks that had been written.   I am not sure how many legacy Unix
implementations implement the semantics that you are hoping for, and I very
much doubt there are any user space programs who depend on such a behavior.

As such, I suspect it's going to be hard to get most developers to care about
implementing this if it's only to be about API semantic purity.   If there was
a cash-rich, say, Japanese corporation that was going to throw $$$ at a company
asking them to fix it, it might happen, if it didn't complicate the
implementation; most developers would be far more interested in keeping the VFS
layer bug-free and long-term maintainable compared to API semantic purity.  Or
if *you* really care, it might be an interesting starter project.

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