Does anyone know if there''s a plan to provide an option to make a BTRFS filesystem a WORM (write-one-read-many)? So essentially, once a file has been written it cannot be altered nor deleted. To delete would require a newfs. I know that there''s extended attributes but root can alter that on individual files. Anyway, thanks in advance for any help. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
There''s support for Read-only snapshots, so you might be able to use that with some clever scripting =\ On Mon, Mar 12, 2012 at 2:36 PM, Fong Vang <sudoyang@gmail.com> wrote:> Does anyone know if there''s a plan to provide an option to make a > BTRFS filesystem a WORM (write-one-read-many)? So essentially, once a > file has been written it cannot be altered nor deleted. To delete > would require a newfs. I know that there''s extended attributes but > root can alter that on individual files. > > Anyway, thanks in advance for any help. > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Mar 12, 2012 at 12:36:13PM -0700, Fong Vang wrote:> Does anyone know if there''s a plan to provide an option to make a > BTRFS filesystem a WORM (write-one-read-many)? So essentially, once a > file has been written it cannot be altered nor deleted. To delete > would require a newfs. I know that there''s extended attributes but > root can alter that on individual files.There''s a btrfs-specific per-inode flag BTRFS_INODE_READONLY, it is used in just one place (to check inode permissions upon write) and denies any write operation. There''s no direct way (like an ioctl call) to either add or remove this flag, so it fullfils one half of what you want. It''s possible to enhance mkfs to set this flag to all files when prefilled from a directory (option -r). For a change in a mounted filesystem, a new ioctl doing the one-way switch to RO would be needed. (I just know that the flag is there and is related to the question, haven''t tested it myself and do not know what was the original intention.) david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Chester posted on Mon, 12 Mar 2012 14:52:47 -0500 as excerpted:> On Mon, Mar 12, 2012 at 2:36 PM, Fong Vang <sudoyang@gmail.com> wrote: >> Does anyone know if there''s a plan to provide an option to make a BTRFS >> filesystem a WORM (write-one-read-many)? So essentially, once a file >> has been written it cannot be altered nor deleted. To delete would >> require a newfs. I know that there''s extended attributes but root can >> alter that on individual files. >> >> Anyway, thanks in advance for any help.> There''s support for Read-only snapshots, so you might be able to use > that with some clever scripting =\[Quote rearranged into standard contextual quote and reply order.] If I''m reading between the lines correctly, that''s not going to suffice. It sounds to me like the request is for an indelible/immutable journal, potentially backed by a legal requirement. Think (US) SOX, Sarbanes-Oxley, requirements, or similar elsewhere. Or consider a criminal computer-related case where an investigator''s every action while analyzing a suspect''s drive is write-once recorded, creating a permanent record to be used in court. Or for that matter, consider the audit trail of an electronic voting machine. In such cases an indelible log that cannot be altered without destruction is vital. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 13 March 2012 10:40:39 David Sterba wrote:> (I just know that the flag is there and is related to the question, > haven''t tested it myself and do not know what was the original > intention.)Not sure it helps, but the commits for these were: commit fdebe2bd70047e057827cba85ba31b2545e31900 Author: Yan <yanzheng@21cn.com> Date: Mon Jan 14 13:26:08 2008 -0500 Btrfs: Add readonly inode flag This patch adds readonly inode flag support. A file with this flag can''t be modified, but can be deleted. Signed-off-by: Chris Mason <chris.mason@oracle.com> and.. commit cb6db4e57632ba8589cc2f9fe1d0aa9116b87ab8 Author: Jeff Mahoney <jeffm@suse.de> Date: Mon Aug 15 17:27:21 2011 +0000 Author: Jeff Mahoney <jeffm@suse.de> Date: Mon Aug 15 17:27:21 2011 +0000 btrfs: btrfs_permission''s RO check shouldn''t apply to device nodes This patch tightens the read-only access checks in btrfs_permission to match the constraints in inode_permission. Currently, even though the device node itself will be unmodified, read-write access to device nodes is denied to when the device node resides on a read-only subvolume or a is a file that has been marked read-only by the btrfs conversion utility. With this patch applied, the check only affects regular files, directories, and symlinks. It also restructures the code a bit so that we don''t duplicate the MAY_WRITE check for both tests. Signed-off-by: Jeff Mahoney <jeffm@suse.com> Signed-off-by: Chris Mason <chris.mason@oracle.com> -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP
I''m sure the OP''s idea was to allow one to write onto the FS, and have Btrfs dealing with the internal requirements of not allowing further modifications on what exists on the FS. Transparently and without any user-level intervention. The thing is that, the complexity will always depend on the wanted semantics. If one wants to simply allow ''new files'', I believe it should be rather easy to implements, but that leads me to questioning "why Btrfs?". OTH, if one does want to allow appending onto a file, but making sure new appends (e.g., those between open() and close()) create a new version of the said file, then Btrfs could work for that: append, set new extents RO, snapshot. Although this may not be as simple, it sure looks quite interesting :-) I guess I''ll be on the lookout for further developments on this thread! (if any) Cheers, Joao On Mar 13, 2012, at 12:17 AM, Chris Samuel wrote:> On Tuesday 13 March 2012 10:40:39 David Sterba wrote: > >> (I just know that the flag is there and is related to the question, >> haven''t tested it myself and do not know what was the original >> intention.) > > Not sure it helps, but the commits for these were: > > commit fdebe2bd70047e057827cba85ba31b2545e31900 > Author: Yan <yanzheng@21cn.com> > Date: Mon Jan 14 13:26:08 2008 -0500 > > Btrfs: Add readonly inode flag > > This patch adds readonly inode flag support. A file with this flag > can''t be modified, but can be deleted. > > Signed-off-by: Chris Mason <chris.mason@oracle.com> > > and.. > > commit cb6db4e57632ba8589cc2f9fe1d0aa9116b87ab8 > Author: Jeff Mahoney <jeffm@suse.de> > Date: Mon Aug 15 17:27:21 2011 +0000 > Author: Jeff Mahoney <jeffm@suse.de> > Date: Mon Aug 15 17:27:21 2011 +0000 > > btrfs: btrfs_permission''s RO check shouldn''t apply to device nodes > > This patch tightens the read-only access checks in btrfs_permission to > match the constraints in inode_permission. Currently, even though the > device node itself will be unmodified, read-write access to device nodes > is denied to when the device node resides on a read-only subvolume or a > is a file that has been marked read-only by the btrfs conversion utility. > > With this patch applied, the check only affects regular files, > directories, and symlinks. It also restructures the code a bit so that > we don''t duplicate the MAY_WRITE check for both tests. > > Signed-off-by: Jeff Mahoney <jeffm@suse.com> > Signed-off-by: Chris Mason <chris.mason@oracle.com> > > -- > Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC > > This email may come with a PGP signature as a file. Do not panic. > For more info see: http://en.wikipedia.org/wiki/OpenPGP--- João Eduardo Luís gpg key: 477C26E5 from pool.keyserver.eu