[UNSOLVED] Read-Only mount: Samba has delete privileges!

[virtualdj]

Hi to all, I'm trying to do a simple thing: let some rsnapshot backups (done with excellent crushdept's guide) to be available read-only inside another Samba share.

I decided to open this thread after I discovered what I think is a bug on Samba (see my posts here).
So let's see the bug "in action"...

1) Create a folder on the QNAP (/opt/var/testdir) using IPKG and add some simple text files.

Code: Select all

[~] # mkdir /opt/var/testdir
[~] # cd /opt/var/testdir/
[/opt/var/testdir] # echo "Test file." > File1.txt
[/opt/var/testdir] # echo "Test file." > File2.txt
[/opt/var/testdir] # echo "Test file." > File3.txt
[/opt/var/testdir] # ls -l
-rw-r--r--    1 admin    administ       11 May 31 18:38 File1.txt
-rw-r--r--    1 admin    administ       11 May 31 18:39 File2.txt
-rw-r--r--    1 admin    administ       11 May 31 18:39 File3.txt

2) OK, we got our files, now let's create a new folder TestShare inside the Public folder.

Code: Select all

[/] # mkdir /share/Public/TestShare
[/] # ls -l /share/Public/
drwxr-xr-x    2 admin    administ     4096 May 31 18:42 TestShare/

3) Now we will mount the testdir as a read-only folder TestShare under the Public folder (i.e. /opt/var/testdir => /share/Public/TestShare).

Code: Select all

[/] # mount --bind /opt/var/testdir /share/Public/TestShare
[/] # mount -o remount,ro /share/Public/TestShare
[/] # mount | grep TestShare
/share/HDA_DATA/.qpkg/Optware/var/testdir on /share/HDA_DATA/Public/TestShare type none (ro,bind)

The last command shows that the mount has been successfull (and with "ro" = read-only mode).

4) Now we can try to delete a file from SSH (with the admin account); it would correctly fail, as the folder is read-only.

Code: Select all

[/] # ls -l /share/Public/TestShare/
-rw-r--r--    1 admin    administ       11 May 31 18:38 File1.txt
-rw-r--r--    1 admin    administ       11 May 31 18:39 File2.txt
-rw-r--r--    1 admin    administ       11 May 31 18:39 File3.txt
[/] # id
uid=0(admin) gid=0(administrators) groups=0(administrators),100(everyone)
[/] # rm -f /share/Public/TestShare/File1.txt
rm: unable to remove `/share/Public/TestShare/File1.txt': Read-only file system

You can see that the user is admin, the files are writable but cannot be removed due to the Read-only file system.

5) Now the bug. Access the Public/TestShare folder from Samba using the admin account. I've tried both from Windows (Vista 64-bit) and Linux Ubuntu 10 (in a virtual machine): you cannot add, edit or rename the files (an "access denied" message pops-up) but
you can DELETE them!

Code: Select all

[/] # ls -l /share/Public/TestShare/

How is it possible? Someone said me that it was due to the permission of the files, but it isn't because under SSH the behaviour is correct.
This "bug" (if it is a bug, and I think it is!) prevents me from mounting the rsnapshot backups into a folder in read-only mode; the only way to work-around it is setting the whole shared folder (i.e. Public) as read-only to the admin user too, but that isn't what I want of course!

I'm on 3.4.2 build 0331T firmware, I have Enable Advanced Folder Permissions disabled and Enable Folder Aggregation enabled but with the list of folders empty. This is my smb.conf (cut down for brevity):

Code: Select all

[global]
workgroup = WORKGROUP
security = USER
server string = NAS Server
        encrypt passwords = Yes
username level = 0
        map to guest = Bad User
null passwords = yes
        max log size = 10
socket options = TCP_NODELAY SO_KEEPALIVE SO_SNDBUF=262144 SO_RCVBUF=131072
os level = 20
preferred master = no
        dns proxy = No
        config file = /etc/config/smb.conf
        smb passwd file=/etc/config/smbpasswd
        username map = /etc/config/smbusers
        guest account = guest
        directory mask = 0777
        create mask = 0777
oplocks = yes
        locking = yes
        disable spoolss = yes
        load printers = no
        dos charset = UTF8
display charset = UTF8
force directory security mode = 0000
        template shell = /bin/sh
veto files = /.AppleDB/.AppleDouble/.AppleDesktop/:2eDS_Store/Network Trash Folder/Temporary Items/TheVolumeSettingsFolder/.@__thumb/.@__desc/:2e*/
        delete veto files = yes
map archive = no
map system = no
map hidden = no
map read only = no
deadtime = 10
use sendfile = yes
case sensitive = auto
unix extensions = no
min receivefile size = 4096
wins support = no
passdb backend = smbpasswd
store dos attributes = yes
client ntlmv2 auth = yes
dos filetime resolution = yes
domain master = auto
local master = yes
inherit acls = yes
wide links = yes

<... removed ...>

[Public]
comment = System default share
path = /share/HDA_DATA/Public
browsable = yes
oplocks = yes
ftp write only = no
public = yes
invalid users =
read list =
write list = "admin",@"everyone","guest","web"
valid users = "root","admin",@"everyone","guest","web"
inherit permissions = yes

Any clues? Thank you!

[TonyPh12345]

Might it have something to do with the fact the filesystem you're BINDING is already referenced as a symlink to another filesystem?

On mine, Public is actually MD0-DATA/Public

In other words, what happens if you don't use the Symlink, but the actual path?

[virtualdj]

what happens if you don't use the Symlink, but the actual path?

For me:

Code: Select all

/share/Public/TestShare   =>   /share/HDA_DATA/Public/TestShare
/opt/var/testdir          =>   /share/HDA_DATA/.qpkg/Optware/var/testdir

So if I use:

Code: Select all

[~] # mount --bind /share/HDA_DATA/.qpkg/Optware/var/testdir /share/HDA_DATA/Public/TestShare
[~] # mount -o remount,ro /share/HDA_DATA/Public/TestShare
[~] # mount | grep TestShare
/share/HDA_DATA/.qpkg/Optware/var/testdir on /share/HDA_DATA/Public/TestShare type none (ro,bind)

Here you can see the grep output of the mount command is the same than on post #1.
As a matter of fact, the "bug" is always there. Same results (Samba-delete works)!

[mjb]

I can confirm this problem. It is not related to rsnapshot. For a quick test I just did the following:

Code: Select all

[/share/Users] # mkdir test
[/share/Users] # touch test/a
[/share/Users] # chown -R Max test
[/share/Users] # mkdir test-bind
[/share/Users] # mount --bind test test-bind
[/share/Users] # mount -o remount,ro test-bind
[/share/Users] # ls -l test*/*
-rw-r--r--    1 Max      administ        0 Jun  1 18:50 test-bind/a
-rw-r--r--    1 Max      administ        0 Jun  1 18:50 test/a
[/share/Users] # rm test-bind/a
rm: cannot remove `test-bind/a': Read-only file system

But from Windows I can delete the file "a" from the samba share. I don't know the reason. I found the following text fragment in the mount manual page which may give a hint (http://unixhelp.ed.ac.uk/CGI/man-cgi?mount+8):

Note that the filesystem mount options will remain the same as those on
the original mount point, and cannot be changed by passing the -o
option along with --bind/--rbind.

All attribute changes (remount) to the bind mount will propagate to the
source mount. The read-only bind mounts are implemented in since Linux
2.6.26.

It looks like the smbd process still uses the original mount attributes?

(I'm using a QNAP TS-239 Pro II, firmware 3.2.7)

[virtualdj]

The read-only bind mounts are implemented in since Linux 2.6.26.

But QNAP has Linux 2.6.33.2 which should have solved the issue...

[mlynchit]

Perhaps... Don't use bind?

[virtualdj]

@ mlynchit
Hi, and thank you for your answer.
I've not completely understood it, though. Can you make an example on how to mount the backup folder read-only?

[mlynchit]

I've found that with the QNAPS, most security is performed at the share level.

Without going over the topic, is it not possible for you to simple set Read Only for the admin user on the share?

I have a "Snapshots" share, and i t's readonly by any network user. Of course, any one who manages to log in via SSH will hvae much more access. But that's just they way the QNAPs are, by default.

If I am WAY off the mark, might I suggest that you create "File system-in-a-file"?

i.e dd of=Backup.disk count=20gig....
mount -o loop,ro Backup.disk... etc..

Is it -o loop to mount a file? Pretty sure thats how I used to test copies of raw partitions.

Michael.

[virtualdj]

Yes, saving the backups to a new shared folder where all users have read access works, but the goal was providing for each shared folder the related backups in read-only mode.
So in this case if a user can read a share, then he would find the backups into that folder and cannot browse the other backup folders. The mounted dir has to be read-only of course, or the user can mess with the backups.

Maybe the issue is related to an old Samba version? Because on a Lenny VM this behaviour doesn't exist.

[mlynchit]

Im all out of ideas

Maybe try changing the UID that smbd runs as.

If smbd is not running as admin, then surely there is NO FREAKING WAY that it could POSSIBLY perform a delete

Michael.

[agarthan]

I know this is an old post, however:

> I have Enable Advanced Folder Permissions disabled...

I think that was the original poster's problem:
He was mounting this resource as a folder *within* the Public folder, but insisting on keeping the Public folder - which is a root folder - set to R/W.
He then wonders why he can't have the mounted resource, which now appears as a subfolder to Public, set to R/O - a different privilege level to its root folder.

BUT you only get to specify different access privileges for the *folders within* a root folder if you have 'Advanced Folder Permissions' turned *ON*.
If it's set to OFF, you can only specify those privileges for entire root folders.

Agarthan

[virtualdj]

Hi agarthan, thanks for posting. It was quite a while that I asked this question and since then I've not tried it anymore.
So, I replicated the tests on the first post with Advanced Folder Permissions switched ON.

If I login using Samba as a normal user, then you can delete the files but when you press F5 to refresh the folder, they magically reappear.
On the contrary, if I login using Samba as admin, then you can still delete the files and they're really deleted.

How do you set up the folder permissions for the TestShare to prevent deletion?


On the screen above, if I try to put the checkmark on Read only for the admin user and then hit Apply, then the checkmark is restored on Read/Write.
Hence, you can still delete the files on the mounted folder (the owner of the folder is admin).

[schumaku]

How do you set up the folder permissions for the TestShare to prevent deletion?

To admin? To the user defined the owner? To normal users (not members of the administrators group)?

Appears QNAP has a reason for force r+w to admin - so the effect is pretty much predictable, isn't it?

[virtualdj]

Yeah, it is indeed.
But I don't understand why enabling Advanced Folder Permission should solve the mount RO problem then.

[schumaku]

Deploying ACL on each of the folders used for the backups per client should do the job in my opinion.

Any attempts to stack shared folders is depreciated in any case (deploying and replacing changed ACL from the QTS or from another admin view is simply to risky) .