Rclone config(secrets) "hidden" away from a user - how?

I contemplate a concept here so go easy on me - I'm still a novice to all this.
I've just learned a hard way, but no biggie, that rclone fails if does not have full access to the folder in which config resides (naturally to the config file itself too).
I'm thinking of a Linux box where systemd's multiple services would mount a remote and do it as a "regular" user(systemd's config), mount separately for each one of multiple users.
"secrets" in the config file are my worry so I wonder is there a way to have it done so those secrets are not accessible by such "regular" user, even if not 100% of the time then 99.99% ideally.

Care to share any thoughts? I'll appreciate.
many thanks, L.

What is your rclone version (output from rclone version)

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

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

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

When a user uses rclone, they need read/write access to the rclone.conf file to update refresh keys/tokens.

If the user is using rclone, they are using the contents of that file and can do everything based on that rclone.conf.

Rclone works by basically assuming the user using the rclone.conf is 'trusted' so they need access to that file and it's content to update.

It's hardly an effort to repeat what others have said many times already - rclone is really very neat - but if there is field it could improve then it'd be 'multi-user' environments(I naturally thinks of Linux "servers").
Some kind of enhancement where a deamon/service would do the work (mainly mounts I have in mind) on user(s) behalves so then users could be kept away from sensitive secrets, etc.

If I was to dare to submit such idea for devel/authors consideration - where do I do that?

ps. I was hoping that when a "mount" has been established then config file could be hidden way from user(s). Would that work?

regards, L.

rclone uses fuse which is user based so that either you mount for a user or if you have root access, you can mount for everyone and use UID/GID to secure it.

It's not a rclone limitation but how fuse works.

Really? How would you do that?
From what I see (I've only started looking) once a mount has been done then all the content in it gets the UID of the mounter user.
What do I miss?

So in my example, I'm mounting as root and making netdata own it:

netdata:x:996:998:netdata:/var/lib/netdata:/usr/sbin/nologin

root@gemini:~# rclone mount gcrypt: /test --allow-other --uid 996 --gid 996

and

felix@gemini:/test$ ls -al hosts
-rw-r--r-- 1 netdata 996 221 Feb 11 10:50 hosts

Options are documented on the rclone mount page:

Sorry, I should have quoted you more fully...

Thus that example you shared does not "fix" the problem nor it does what the quote says. Others can use the mount yes but there is no UID/GUI separation/preservation, all belongs that to 'netdata'

I have a simple setup where I get that separation, naturally via separate mounts (via systemd) for given users but I have no remedy to my original worry - hide sensitive credential away from users -> not possible if 'rclone' process(es) needs constant full access to rclone config file.

Sorry as I'm not following as you can set UID/GID and a few more flags to setup any permissions that you want and it acts like normal Linux depending on what you are trying to achieve.

Another example if you wanted to lock down '/test" to just the user netdata as I left it open to read.

root@gemini:~# rclone mount gcrypt: /test --allow-other --uid 996 --gid 996 --umask 077 --default-permissions

and

felix@gemini:~$ cd /test
-bash: cd: /test: Permission denied

You'd have to share some specifics if you want to me a write an example that correlates to what you are trying to achieve

So in my example only root can see rclone.conf and the netdata user can see files.

hi,

not sure what cloud service you are using.
pehaps, if you use services files, not tokens, then rclone would not full acess to the config file.

Would what you say work off dropbox?
At the same time: which storage cloud providers fix it that way?

many thanks, L.

not an expert at that,
aws s3 and clones like wasabi.

Rclone requires access to the rclone.conf and if the user is launching the process, they can see the file/read it and see the contents of the file and grab them that way similar to anything else in the rclone.conf

We have a ticket https://github.com/rclone/rclone/issues/3655 requesting a separate file for mutable state aka tokens. If someone (maybe you?) implemented it, one could put that in a place with tough permissions.

You can completely hide non-mutable secrets right now. Here is an example for systemd

/secrets/mystorage.env: (chmod 600; chown root)
RCLONE_MYREMOTE_PASSWORD=supasicret
/public/mystorage.conf:
.....
/etc/systemd/system/mymount.service:
EnvironmentFile=/secrets/mystorage.env
ExecStart=rclone --config /public/mystorage.conf mount ....

If you check the proc/environment that is running, it's there or did I do something wrong?

My service file line:

EnvironmentFile=/tmp/mypass.env

file set:

root@gemini:/proc/3693518# cat /tmp/mypass.env
RCLONE_GD_PASSWORD=supasicret
root@gemini:/proc/3693518# exit
logout
felix@gemini:~$ cat /tmp/mypass.env
cat: /tmp/mypass.env: Permission denied

but if you check the running process, you can find any environment variable set.

felix    3693518       1  0 10:51 ?        00:00:00 /usr/bin/rclone mount gcrypt: /test --allow-other --dir-cache-time 1000h --log-level NOTICE --log-file /opt/rclone/logs/test.log --poll-interval 15s --umask 002 --user-agent randomappname102
felix    3695423 2477716  0 10:53 pts/0    00:00:00 grep --color=auto rclone
felix@gemini:~$ cat /proc/3693518/environ | grep PASS
Binary file (standard input) matches
felix@gemini:~$ cat /proc/3693518/environ
LANG=C.UTF-8PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binNOTIFY_SOCKET=/run/systemd/notifyHOME=/home/felixLOGNAME=felixUSER=felixSHELL=/bin/bashINVOCATION_ID=628129e109b64f9caef012b84feea776JOURNAL_STREAM=9:2772613092RCLONE_CONFIG=/opt/rclone/rclone.confRCLONE_GD_PASSWORD=supasicretfelix@gemini:~$

If you want to hide it from ROOT, run it on another box

1 Like

I didn't run the command as root as I can see it as the user "felix" as that's what is shown in my output.

I think the OP was asking about hiding from the user and my point was the user running the process can see their environment variables, which means the root owned file doesn't matter.

i thought that this would prevent the environment variable problem?

https://rclone.org/docs/#password-command-spaceseplist

Quick experiment on my ubuntu 18.04 where I run rclone as root from systemd

root# ls -l /proc/12894/environ
-r-------- 1 root root 0 Feb 17 19:37 /proc/12894/environ
deex$ cat /proc/12894/environ
cat: /proc/12894/environ: Permission denied
deex$ ps -efa |grep rclone
root     12894     1  0 19:35 ?        00:00:00 /usr/bin/rclone cmount --gid=911 --allow-other --vfs-cache-mode=writes --dir-cache-time=30s wrt77ext3: /mnt/rc/wrt77ext3

As expected, non-root can't access /proc/<root's>
I think you run rclone as felix

If you run process under user, you can't hide anything from that user. They can read the process memory, at the very least

I think we're crossing the streams as they say as we're both correct but answering different questions.

If you run rclone as root, you can secure rclone.conf as root and the user would never see it. I gave an answer for that, which is the same for environment variables running as a process.

If you run rclone as a user, the user can see their environment variables, which is what I thought you were suggesting to the OP, which does not meet the requirement.

Hope that clears up the confusion.