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
| ||
|
Date: Mon, 16 Mar 2009 14:36:16 +0100 From: Jan Kara <jack@...e.cz> To: linux-ext4@...r.kernel.org Subject: Same magic in statfs() call for ext? Hi, I've just noticed that EXT2_SUPER_MAGIC == EXT3_SUPER_MAGIC == EXT4_SUPER_MAGIC. That is just fine for the disk format but as a result we also return the same magic in statfs() syscall and thus a simple application has hard time recognizing whether it works on ext2, ext3 or ext4 (it would have to parse /proc/mounts and that is non-trivial if not impossible when it comes to bind mounts). So should not we return different magic numbers depending on how the filesystem is currently mounted? Now you may ask why should the application care - and I agree that in the ideal world it should not. But for example there's a thread on GTK mailing list [1] where they discuss the problem that with delayed allocation and ext4, user can easily lose his data after crash (Ted wrote about it here in some other mail some time ago). So they would like to call fsync() after the file is written but on ext3 that is quite heavy and because of autosave saving happens quite often. So they'd do fsync() only if the filesystem is mounted as ext4... So I'm writing here so hear some opinions on returning different magic numbers from statfs(). Honza [1] http://mail.gnome.org/archives/gtk-devel-list/2009-March/msg00082.html -- Jan Kara <jack@...e.cz> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists