[Bugs] [Bug 1505807] New: files are appendable on file-based worm volume

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1505807

            Bug ID: 1505807
           Summary: files are appendable on file-based worm volume
           Product: Red Hat Gluster Storage
         Component: unclassified
          Severity: low
          Assignee: amukherj at redhat.com
          Reporter: vpandey at redhat.com
        QA Contact: rhinduja at redhat.com
                CC: atumball at redhat.com, bugs at gluster.org,
                    jurgen.reij at ingbank.com, ksubrahm at redhat.com,
                    mhergaar at redhat.com, rhs-bugs at redhat.com,
                    sankarshan at redhat.com, smohan at redhat.com,
                    storage-qa-internal at redhat.com



+++ This bug was initially created as a clone of Bug #1487504 +++

Description of problem:
it is possible to append a file in immutable and undeletable state on a
file-based worm volume

Version-Release number of selected component (if applicable):
3.11.2

How reproducible:
[vagrant at client1 share]$ date && echo "testfile" >> testfile
Wed Aug 30 09:03:51 CEST 2017
[vagrant at client1 share]$ date && rm testfile
Wed Aug 30 09:04:07 CEST 2017
rm: cannot remove ‘testfile’: Read-only file system
[vagrant at client1 share]$ date && echo "testfile" >> testfile
Wed Aug 30 09:04:12 CEST 2017
[vagrant at client1 share]$ date && echo "testfile" >> testfile
Wed Aug 30 09:05:17 CEST 2017
[vagrant at client1 share]$ date && rm testfile
Wed Aug 30 09:05:21 CEST 2017
[vagrant at client1 share]$



Steps to Reproduce:
1.create volume. enable file-based worm
2.features.worm-file-level: on
features.default-retention-period: 60
features.auto-commit-period: 5
3.follows steps in "how reproducible"

Actual results:
the file was appended

Expected results:
it should not be possible to append files in immutable undeletable state 


Additional info:

--- Additional comment from Jurgen Reij on 2017-09-01 02:27 EDT ---



--- Additional comment from Jurgen Reij on 2017-09-01 02:27 EDT ---



--- Additional comment from Karthik U S on 2017-09-06 03:16:15 EDT ---

It is not appending any content to the worm-retained file. The problem here is
when we do an append write we do not print the EROFS error. If you check the
actual contents of the file after the append write it won't be changed.
Try appending some new contents instead of doing
echo "testfile" >> testfile
which is same as the original content of the file. If you see the brick logs it
will show the EROFS error message for the append writes.

If you can see the new contents appended to the worm-retained/worm file, please
let me know.

--- Additional comment from Jurgen Reij on 2017-09-28 05:40:46 EDT ---

Karthik,

See my results:

[vagrant at client1 share]$ date && echo "test1" >> testfile
Thu Sep 28 11:38:57 CEST 2017
[vagrant at client1 share]$ date && echo "test2" >> testfile
Thu Sep 28 11:39:10 CEST 2017
[vagrant at client1 share]$ cat testfile
test1
test2

--- Additional comment from Karthik U S on 2017-09-28 06:20:37 EDT ---

Hi Jurgen Reij,

Current code does not have the state transition mechanism in the write code
path. This is a bug and we have a dependency on some other thing for this. Once
that is fixed we will do transition in the write path as well, so the next
writes will be blocked.
Let me try to explain the scenario in your test. First you created the
testfile. After 13 seconds you are trying to do append write, and expect it to
be blocked since the auto-commit-period is 10secs. Since it is an append write,
and not link, unlink, rename, or truncate (the only 4 fops which does the state
transition in the current code), it won't check for the state transition  and
does the next write. So the content gets updated.
Instead of checking only the date, check the stat of the file. The atime will
point to a future value after state transition to worm-retained state which
will then be equal to the "time at which transition happened + the retention
period". In normal state it will allow append write.

We will fix the behaviour so write fops will also do the state transition.

--- Additional comment from Worker Ant on 2017-10-24 05:15:24 EDT ---

REVIEW: https://review.gluster.org/18560 (write once read many: file appendable
in worm state) posted (#1) for review on master by Vishal Pandey
(vpandey at redhat.com)

--- Additional comment from Worker Ant on 2017-10-24 05:40:20 EDT ---

REVIEW: https://review.gluster.org/18560 (write once read many: file appendable
in worm state) posted (#2) for review on master by Vishal Pandey
(vpandey at redhat.com)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=tNzxy67neq&a=cc_unsubscribe