Bug 10430 - VFS_WORM: Deleting/modifying files is possible from Linux client
Summary: VFS_WORM: Deleting/modifying files is possible from Linux client
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: VFS Modules (show other bugs)
Version: 4.19.3
Hardware: x64 All
: P5 normal (vote)
Target Milestone: 4.20
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks: 10427
  Show dependency treegraph
 
Reported: 2014-02-07 16:04 UTC by Marc Muehlfeld
Modified: 2024-01-16 17:34 UTC (History)
5 users (show)

See Also:


Attachments
Patch for worm with workaround (4.23 KB, patch)
2014-09-09 11:50 UTC, Mikhail Skorzhinskiy
no flags Details
New patch for worm (6.83 KB, patch)
2014-10-10 13:45 UTC, Mikhail Skorzhinskiy
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Muehlfeld 2014-02-07 16:04:23 UTC
I've setup a demo share with VFS_WORM (module is only in master at the moment):

[demo]
        comment =
        path = /srv/samba/WORM2
        browseable = no
        force create mode = 0660
        force directory mode = 2770
        guest ok = no
        csc policy = disable
        vfs objects = worm
        worm:grace_period = 20   # 20 seconds


On Windows, the WORM functionality works like expected. After 20 seconds, no write operation is allowed (modify, delete, etc.).



Problem 1:
===========

But if the shares is mounted on a Linux client, files can be deleted with "rm", what shouldn't be possible:


# mount -t cifs //server/demo /mnt/ -o username=technik,domain=MUC

# ls -la /mnt/demo/hallo.txt
-rwxrw---- 1 technik imgm 0  7. Feb 16:48 /mnt/demo/hallo.txt

# date
Fr 7. Feb 16:53:17 CET 2014

# stat /mnt/demo/hallo.txt
  File: „/mnt/demo/hallo.txt“
  Size: 0               Blocks: 0          IO Block: 16384  reguläre leere Datei
Device: 12h/18d Inode: 1197724215  Links: 1
Access: (0760/-rwxrw----)  Uid: ( 1092/ technik)   Gid: ( 8049/    imgm)
Access: 2014-02-07 16:48:07.632288200 +0100
Modify: 2014-02-07 16:48:07.632288200 +0100
Change: 2014-02-07 16:48:09.739356900 +0100

# rm /mnt/demo/hallo.txt

# ls -la /mnt/demo/hallo.txt
ls: Zugriff auf /mnt/demo/hallo.txt nicht möglich: Datei oder Verzeichnis nicht gefunden





Problem 2:
===========

Also you can use "touch" from a Linux client to a file, to reset the ctime, what makes the file writeable from any client until the grace period expires again. Changing the timestamp (like ctime) should not be possible, if the grace period is over.


# mount -t cifs //server/demo /mnt/ -o username=technik,domain=MUC

# echo "hallo" > /mnt/demo/test.txt
-bash: /mnt/demo/test.txt: Keine Berechtigung

# touch /mnt/demo/test.txt

# echo "hallo" > /mnt/demo/test.txt

# cat /mnt/demo/test.txt
hallo
Comment 1 Jeremy Allison 2014-02-28 00:59:29 UTC
I'll take a look..

Jeremy.
Comment 2 Björn Baumbach 2014-02-28 09:28:40 UTC
(In reply to comment #1)
> I'll take a look..
> 
> Jeremy.

Hi Jeremy,

the source of the problem is that trans2setfilepathinfo() does not go through SMB_VFS_CREATE_FILE().
All other functions like unlink, mkdir, ... do that. I tried to adapt the trans2setfilepathinfo(), but this breaks some torture tests. But the worm functionality is working with my changes, e.g. when I try to touch or remove the file.

There is an additional issue. The following fails with "Permission denied" (whats correct) but truncates "testfile" and sets the ctime:
echo "test" > testfile

Disabling the Unix Extensions makes the problem worse.

Björn
Comment 3 Mikhail Skorzhinskiy 2014-09-09 11:50:06 UTC
Created attachment 10267 [details]
Patch for worm with workaround

Hello,

I have an idea to wrap ntimes_fn and open_fn. What do you think about this? Seems it will fix all problems listed below. But Im not sure, may be there are pitfalls in this soulution.

And I must warn, that I do this for samba 3.5.6: I port vfs_worm.c from 4.1 for 3.5.6, make changes, check that they working and then port this changes back to show what I done. But I do not check this changes in samba 4.1.

Mikhail
Comment 4 Marc Muehlfeld 2014-09-11 13:07:53 UTC
Hello Mikhail,

thanks for trying to solve this.


(In reply to comment #3)
> I have an idea to wrap ntimes_fn and open_fn. What do you think about this?
> Seems it will fix all problems listed below. But Im not sure, may be there are
> pitfalls in this soulution.

Can you post the patch with a link to this bug report to samba-technical, please? There are more developers who can tell something about VFS and tell you about possible pitfalls, etc. Thanks.




> And I must warn, that I do this for samba 3.5.6: I port vfs_worm.c from 4.1 for
> 3.5.6, make changes, check that they working and then port this changes back to
> show what I done. But I do not check this changes in samba 4.1.

I tried applying your patch to 4.1 to test it's general functionality. But it fails compiling. Do you have the change to adapt it for 4.1 or git master?
Comment 5 Mikhail Skorzhinskiy 2014-10-10 13:45:43 UTC
Created attachment 10341 [details]
New patch for worm

> I tried applying your patch to 4.1 to test it's general functionality. But it fails compiling. Do you have the change to adapt it for 4.1 or git master?

Sorry for incorrect information -- I adapt changes for git master. In new patch I fix compile-time bugs, so try it again please. But this changes steel tested only for 3.5.6.

Farther, I found new bug -- with old patch you can use chmod, so, I wrap chmod call too.
Comment 7 Björn Jacke 2023-12-27 18:57:19 UTC
Is this still an issue or did the vfs reqorks magically fix this already?
Comment 8 Björn Jacke 2023-12-29 00:19:11 UTC
this is still a problem, posix chmod is still possible and that resets the ctime and thus makes the file writable again.

More problems: a worm'ed directory and not deletable but it is still possible to be create files in it. This also resets the ctime and the mtime of the directory and thus makes the directory fully "un-warm"'ed again.
Comment 9 Samba QA Contact 2024-01-16 15:45:12 UTC
This bug was referenced in samba master:

30fea0e959229ee583bc76490aff5e54bc7f5be8
Comment 10 Björn Jacke 2024-01-16 17:34:24 UTC
the directory r/w issue from comment #8 is not covered but I think making directories r/o is also not desirable. The original reported issues on files are fixed now in master and will be fixed in the upcoming 4.20 version.