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
| ||
|
Message-ID: <20150930161112.GA16068@thunk.org> Date: Wed, 30 Sep 2015 12:11:12 -0400 From: Theodore Ts'o <tytso@....edu> To: Andreas Dilger <adilger@...ger.ca> Cc: "Darrick J. Wong" <darrick.wong@...cle.com>, "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org> Subject: Re: [PATCH] tune2fs: don't change UUID on a mounted metadata_csum fs On Tue, Sep 29, 2015 at 07:21:08PM -0600, Andreas Dilger wrote: > > I don't see how changing the UUID for mounted file systems can work > for metadata_csum file systems? > > Wouldn't this cause a checksum error for every piece of metadata? Tune2fs tries to update every piece of metadata when you run a command like "tune2fs -U random /dev/sda1". The danger is in the fact that tune2fs is modifying every bit of metadata while the file system is mounted. If you do this with "debugfs -w -R "ssv uuid random" /dev/sda1", it will break every metadata in the system, because it doesn't try to update every bit of metadata. I suppose a better choice might be to add a debugfs command which does update the UUID, and use that command as an emergency override when there's no other clean way of handling things. It's more understood by users that using debugfs is inherently dangerous, where as it's not quite as obvious that -f means "here be dragons". (Hence the rationale of using "-f -f" which we've used in other cases.) The problem with --force-uuid is that it means dragging in getopt_long(), and having a fallback when compiling e2fsprogs on a system that doesn't support getopt_long(), or if you are using a libc, such as Bionic, dietlibc, etc., that doesn't have getopt_long(). - Ted -- 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