With 'user_allow_other' - 'perms' have no effect?

Help and Support
1

Hi guys,

I 'rclone' mount with:

--dir-perms 0700
--file-perms 0600
--allow-other
...

And I end up with:
..
drwxr-x---. 2 be be 6 Feb 17 09:16 be
drwx------. 1 me me 0 Feb 17 18:04 me # <- HERE

yet I do:

-> $ sudo -u be ls /0-cloud.storage/dropbox/me
Ebooks

Or even if I interactively shell in as 'be' user, still, can see what is in 'me'

What the heck is going on would anybody know?
I confess I was expecting such a mount to be available, in this case, to 'me' user(& root of course)

thanks, L.

What is your rclone version (output from rclone version)

rclone-1.55.0.beta.5175.aee3bfb17.fix.dropbox.scopes-1.x86_64

Which OS you are using and how many bits (eg Windows 7, 64 bit)

Centos Stream
fuse-2.9.7-12.el8.x86_64

Which cloud storage system are you using? (eg Google Drive)

Dropbox.

The command you were trying to run (eg rclone copy /tmp remote:tmp)

Paste command here

The rclone config contents with secrets removed.

Paste config here

A log from the command with the -vv flag

Paste  log here
2

What are you trying to do?

Rclone uses fuse, which is a user namespace file system meaning on the user running it can see.

Allow-other lets everyone "see" the file system.

Depending on what you want do, there are various flags to do what you want.

I think you want to add:

--default-permissions --dir-perms 0700 --file-perms 0600

and that should do it.

3

But whole logic here is twisted. I do not know what is the culprit here, in my mind it makes no sense.
To me it seems that use of 'user_allow_other' completely, really completely defeats the purpose & function of rclone's 'perms', 'umask' and maybe more.

Removal or dismissal of 'user_allow_other' does what one would expect, well, what I expected, though then it looks bit messy if was to say,...
-> ls
d?????????? ? ? ? ? ? me
Then others do get 'Permission denied' as expected, but then...
other processes, okey - tried only samba so far, which, like Samba spawn off children running as "regular" users, cannot get to such mount point neither.
In other words here with Samba example - Samba client will not be able to connect as user 'me' (nor any other user obviously) to a share which points to/uses such rclone's mount point.

4

Rclone is a fuse based file system on Linux. A fuse base file system is usually in the user namespace only. So the user runs rclone and only that user can see it. Regardless of any permission or anything else, that's what you get without allow-other.

Allow-other needs to be configured via root in /etc/fuse.conf and allows what is normally a user only based namespace to be seen by everyone on that server, which in a shared environment is generally bad so most providers won't allow it to be turned on.

Once you turn on allow-other, you can then configure other user's to hit the mount and further configure/lock it down with the normal Linux permission with UID/GID and the masking for the directory and files you've described above.

If you add another layer on top of that, Samba, you need to decide what how that is going to work and how you'd secure that. I personally would not layer samba on top of rclone as I'd just run it on the client needed as layers and layers of things tend to break and are complex plus the amount of CIFS bugs that I've seen would make me never use it just for that fact alone.

1 Like
5

It is that either you did not read what I said or I failed to get the message across, or both.
What you say in that quote does not work and probably not just in my setup, should be easy to reproduce.
If I do use 'user_allow_other' and tell rclone to ' --allow-other' then it does not matter - as I explained earlier - what args to rclone I use to set permission. I can rclone to set perm that result in rclone 'mount' is:

drwx------. 1 me me 0 Feb 17 18:04 me # <- HERE

And anybody who has rX to parent folder is able to see inside above dir, anybody.
So unless by "..mount and further configure/lock it down with the normal.." you think of some neat tricks then I have no idea how you make it work.

6

I don't know what you are doing since you've only shared snippets.

Example of what I said as it works just fine:

root@gemini:~# rclone mount gcrypt: /test --default-permissions --dir-perms 0700 --file-perms 0600

The user root can see it as that's all I configured it as and the user felix cannot see into that directory.

root@gemini:/test# ls -al hosts
-rw------- 1 root root 221 Feb 11 10:50 hosts
root@gemini:/test# exit
logout
felix@gemini:~$ cd /test
-bash: cd: /test: Permission denied
felix@gemini:~$

If you want to share some commands and the output, I'm happy to help.

7

Gee man.. really?
Did I not say: If I do use 'user_allow_other' and tell rclone to ' --allow-other' ...
Did you not say: Once you turn on allow-other, you can then configure other user's to hit the mount and further configure/lock it down with the normal...

What do you say those lines mean?

I also said and showed that without 'user_allow_other' I get:

-> ll
d?????????? ? ? ? ? ? me

no matter what 'perms' I tell rclone to set.
I also said what I do should be easily reproducible, though it could specifically be rclone version and Centos stream I use.

8

What's the full command you are running?
What's the full output of the directory listing?

9

Suffices to say, what I've been saying all along - use '--allow-other' and whatever perms(include umask too) to rclone to see that: any user can access a mount point content, even if it's 700.
Or don't use '--allow-other' (also no 'user_allow_other') to get eg.
-> ll
d?????????? ? ? ? ? ? me

That's what I see in my setup, but never mind for now. I think we are talking in circles already.

cheers, L.

10

Can you post the full command you are using?

11

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.