linux-ext4 - Re: support freeze operation like xfs

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

Date:	Fri, 26 Jan 2007 20:10:13 -0500
From:	Theodore Tso <tytso@....edu>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Vitez Gabor <vitezg@...f.hu>, linux-ext4@...r.kernel.org
Subject: Re: support freeze operation like xfs_freeze

On Fri, Jan 26, 2007 at 04:23:22PM -0600, Eric Sandeen wrote:
> xfs_freeze is actually -designed- to exit without unfreezing the 
> filesystem, FWIW, for better or worse.  And I suppose there is all sorts 
> of mayhem that could stem from setuid programs of all stripes...

I had a vague memory of that, but I probably supressed the horror.  :-)

> But anyway, on a less OT-topic, it has always seemed a little weird to 
> me that you can -only- freeze a filesystem on an lvm block device. 
> Surely there are occasionally legitimate reasons to freeze a filesystem 
> on an arbitrary block device, if the filesystem can support it?

The issue isn't that you can only freeze a filesystem on an LVM block
device; in fact, you can't.  You can only take a snapshot on an LVM
block device.  I wish you could take snapshots on arbitrary block
devices --- the EVMS1 kernel patches allowed that --- but
unfortunately they were implemented in a way that the kernel community
decided was too ugly to let live, or at least merge into mainline.

> I don't see how direct exposure to freezing routines via LVM ioctls is 
> any less dangerous than direct exposure to freezing routines on 
> /dev/hda1... 

So the issue is that you *don't* have direct expusire to the freezing
routines via LVM ioctl's.  All you can do is request a snapshot, and
the LVM ioctl's freeze the filesystems, take the snapshot and then
unfreeze the filesystem.  

You're right that the BLKROSET ioctls are probably just as dangerous
as well, and of course root can do all sorts of things like running
mkfs, or dd'ing into /dev/kmem, etc.  I think though the issue was
that someone requested a user mode program that was accessible via a
shell script, probably because XFS had that functionality, and the
concern was that few people trusted system administrators to be able
to handle such power responsibly.  Freezing the filesystem for hour or
minutes seems like a very bad idea, and that's exactly the sort of
thing that I can imagine a clueless level one system administrator
doing.  ("I know!  I'll freeze the filesystem while I backup all 30 TB
of it, and then I'll unfreeze it.")

The question really is what are the legimate uses of such a facility
where you wouldn't be better off taking a snapshot and then doing the
backup dump on the snapshot?  The real issue is that we can't take
snapshots on plain block devices, but that might be the better problem
to solve....

						- 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