immutable (WORM) file system

immutable (WORM) file system

[Fong Vang]

Does anyone know if there's a plan to provide an option to make a
BTRFS filesystem a WORM (write-one-read-many)? =A0So essentially, once =
a
file has been written it cannot be altered nor deleted. =A0To delete
would require a newfs. =A0I 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

Re: immutable (WORM) file system

[Chester]

There's support for Read-only snapshots, so you might be able to use
that with some clever scripting =3D\

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)? =A0So essentially, onc=
e a
> file has been written it cannot be altered nor deleted. =A0To delete
> would require a newfs. =A0I 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 =A0http://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

Re: immutable (WORM) file system

[Duncan]

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 BT=
RFS
>> filesystem a WORM (write-one-read-many)? =C2=A0So essentially, once =
a file
>> has been written it cannot be altered nor deleted. =C2=A0To delete w=
ould
>> require a newfs. =C2=A0I know that there's extended attributes but r=
oot 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 =3D\

[Quote rearranged into standard contextual quote and reply order.]

If I'm reading between the lines correctly, that's not going to suffice=
=2E =20
It sounds to me like the request is for an indelible/immutable journal,=
=20
potentially backed by a legal requirement.

Think (US) SOX, Sarbanes-Oxley, requirements, or similar elsewhere.  Or=
=20
consider a criminal computer-related case where an investigator's every=
=20
action while analyzing a suspect's drive is write-once recorded, creati=
ng=20
a permanent record to be used in court.  Or for that matter, consider t=
he=20
audit trail of an electronic voting machine.

In such cases an indelible log that cannot be altered without destructi=
on=20
is vital.

--=20
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

Re: immutable (WORM) file system

[David Sterba]

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)? =A0So essentially, onc=
e a
> file has been written it cannot be altered nor deleted. =A0To delete
> would require a newfs. =A0I 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 use=
d
in just one place (to check inode permissions upon write) and denies an=
y
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

Re: immutable (WORM) file system

[Chris Samuel]

[-- Attachment #1: Type: Text/Plain, Size: 1817 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

Re: immutable (WORM) file system

[João Eduardo Luís]

[-- Attachment #1: Type: text/plain, Size: 2872 bytes --]

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 






[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 495 bytes --]