Different behaviour between onedrive called from command line to service (systemd) caused by PrivateUsers=true

[Swallowtail23]

Hi, this post started out as me looking for some help with inconsistency from onedrive called on the command line (as root) and run under systemd service (also as root). But as I worked through the post i worked out the issue, so I'm posting here in case anyone else hits similar.

RHEL9, running 2.4.22.

Background - replacement file server, 1TB of data previously synced to onedrive. New server run up, data drives detached and attached to new server, and mounted into /root/OneDrive/EMP95-sync, same as previous server. I ran onedrive --synchronize --resync --verbose from the command line, and over a couple of days it ran through the entire 1TB, and reached "Sync with onedrive is complete". All good. I can now repeat that outcome from the command line with onedrive --monitor - it runs through the entire db, complains about some desktop.ini files being skipped, then reaches "Sync with onedrive is complete".

Then I tried starting the service... and it all went pear-shaped. It started deleting files from onedrive, and nuked about 250GB before I realised what it was doing and stopped it. I re-ran from the command line, and spent another couple of days re-uploading the 250GB, until it again ended up at "sync complete".

At this point, rather gun-shy, I set dry-run in the config file. Re-ran from the command line - all good.

[root@emp95 home]# onedrive --monitor
Configuration file successfully loaded
config file has been updated, checking if --resync needed
DRY-RUN Configured. Output below shows what 'would' have occurred.
Configuring Global Azure AD Endpoints
Initializing the Synchronization Engine ...
Initializing monitor ...
OneDrive monitor interval (seconds): 300
Starting a sync with OneDrive
Uploading differences of ~/OneDrive
Uploading new items of ~/OneDrive
...a bunch of skipped items...
Sync with OneDrive is complete

So then I tried systemctl start onedrive again...

Yikes, fortunately dry-run is configured:

Dec 13 21:36:21 emp95.simonandkate.lan systemd[1]: Started OneDrive Free Client.
Dec 13 21:36:21 emp95.simonandkate.lan onedrive[252915]: Configuration file successfully loaded
Dec 13 21:36:21 emp95.simonandkate.lan onedrive[252915]: config file has been updated, checking if --resync needed
Dec 13 21:36:21 emp95.simonandkate.lan onedrive[252915]: DRY-RUN Configured. Output below shows what 'would' have occurred.
Dec 13 21:36:21 emp95.simonandkate.lan onedrive[252915]: Configuring Global Azure AD Endpoints
Dec 13 21:36:24 emp95.simonandkate.lan onedrive[252915]: Initializing the Synchronization Engine ...
Dec 13 21:36:24 emp95.simonandkate.lan onedrive[252915]: Initializing monitor ...
Dec 13 21:36:24 emp95.simonandkate.lan onedrive[252915]: OneDrive monitor interval (seconds): 300

So far so good. Then a bunch of permission errors, e.g.:

Dec 13 21:36:24 emp95.simonandkate.lan onedrive[252915]: ERROR: The local file system returned an error with the following message:
Dec 13 21:36:24 emp95.simonandkate.lan onedrive[252915]:   Error Message:    ./EMP95-sync/home/ftp/upload: Permission denied
Dec 13 21:36:24 emp95.simonandkate.lan onedrive[252915]: ERROR: The local file system returned an error with the following message:
Dec 13 21:36:24 emp95.simonandkate.lan onedrive[252915]:   Error Message:    ./EMP95-sync/home/server: Permission denied

...a heap more... ...then it starts deleting stuff, e.g.:

Dec 13 21:36:25 emp95.simonandkate.lan onedrive[252915]: Starting a sync with OneDrive
Dec 13 21:36:25 emp95.simonandkate.lan onedrive[252915]: Uploading differences of ~/OneDrive
Dec 13 21:36:33 emp95.simonandkate.lan onedrive[252915]: Deleting item from OneDrive: EMP95-sync/home/server/.fetchids
Dec 13 21:36:33 emp95.simonandkate.lan onedrive[252915]: Deleting item from OneDrive: EMP95-sync/home/server/.bash_history
Dec 13 21:36:33 emp95.simonandkate.lan onedrive[252915]: Deleting item from OneDrive: EMP95-sync/home/server/.muttrc

...a heap more deletes, and then it says "complete" and drops to monitoring.

I figured the only thing different are the service file hardenings - and true enough, it is PrivateUsers which causes it. Comment that out, and the service runs the same as the command line.

I realise this is not a OneDrive client issue (it is working well, thank you!) but maybe worth dropping into documentation somewhere that this can happen.

[abraunegg]

@Swallowtail23

I figured the only thing different are the service file hardenings - and true enough, it is PrivateUsers which causes it.

Thanks for the valuable feedback. This will be a direct effect of #2205 and the blast radius on this is going to be pretty big.

I am going to update the main code, but I think this may even warrant a v2.4.23 release as files should never be deleted because of a systemd option being enabled ......

@bluca - As you can see - not everyone runs Debian | Ubuntu - and your PR is now causing a really bad outcome. I guess the implications of these options are not really understood by the systemd developers ....

[bluca]

Ah I see you changed the PR - my change removed all these no-ops as can be seen here in my last push:

b98dcf0

But then you pushed to the branch and added it back:

2d46080

[abraunegg]

@bluca

my change removed all these no-ops as can be seen here in my last push

Because all those were verified and implemented by OpenSuSE and were verified as working ... your PR would have removed a working security item ....

[bluca]

it is not working, it's a no-op without enabling user namespaces

[Swallowtail23]

Uh? How would removing a non-working no-op ProtectSystem= cause files to be deleted?

Private Users not ProtectSystem

[Swallowtail23]

Little wonder... Noting what it does, it explains the permissions errors followed by an inability to see the files, hence nuking the remote ones:

PrivateUsers

Takes a boolean argument. If true, sets up a new user namespace for the executed processes and configures a minimal user and group mapping, that maps the "root" user and group as well as the unit's own user and group to themselves and everything else to the "nobody" user and group. This is useful to securely detach the user and group databases used by the unit from the rest of the system, and thus to create an effective sandbox environment. All files, directories, processes, IPC objects and other resources owned by users/groups not equaling "root" or the unit's own will stay visible from within the unit but appear owned by the "nobody" user and group. If this mode is enabled, all unit processes are run without privileges in the host user namespace (regardless if the unit's own user/group is "root" or not). Specifically this means that the process will have zero process capabilities on the host's user namespace, but full capabilities within the service's user namespace. Settings such as CapabilityBoundingSet= will affect only the latter, and there's no way to acquire additional capabilities in the host's user namespace. Defaults to off.