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  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.

Powered by blists - more mailing lists