issue with signald and mautrix-signal running with different user/group

[celogeek]

I've got installation with signald running as user signald, and mautrix-signal running as user mautrix-signal.

I've got issue with attachments. When someone sends me a picture, it doesn't appear in matrix and I've got a failed to delete /var/lib/signald/attachment/xxx.

I suppose mautrix try to delete a file generated by signald.

is it possible to ask signald to delete the attachment instead of doing it directly ?

To fix the issue I run both jobs with mautrix-signal user, and ensure path are properly setup in the config file.

Also after the fix the picture is properly working. But previous try is not sync anymore. is they a way to resync the history to get the missing/failed event?

Should I remove the attachment which failed to delete ?

[celogeek]

I see an option to avoid delete attachment on mautrix-signal. I guess you can ask signald to do it for now ?

So if I have signald and mautrix running with the same user I can leave that on. if not, I should turn that off.

And of course mautrix should have enough right to read the file from signald directly.

[jeena]

I have the same problem, thanks for the idea to run them as the same user.

[podiki]

Same here, and setting remove_file_after_handling doesn't fix it, but running signald/bridge as same user does. Is there something better to do (this requires using chown for signald data and changing the service file)?

Mar 23 13:29:00  python[7309]: [2021-03-23 13:29:00,365] [ERROR@mausignald] Exception in event handler
Mar 23 13:29:00  python[7309]: Traceback (most recent call last):
Mar 23 13:29:00  python[7309]:   File "/usr/lib/python3.9/site-packages/mausignald/signald.py", line 51, in _run_event_handler
Mar 23 13:29:00  python[7309]:     await handler(event)
Mar 23 13:29:00  python[7309]:   File "/usr/lib/python3.9/site-packages/mautrix_signal/signal.py", line 50, in on_message
Mar 23 13:29:00  python[7309]:     await self.handle_message(user, sender, evt.data_message)
Mar 23 13:29:00  python[7309]:   File "/usr/lib/python3.9/site-packages/mautrix_signal/signal.py", line 99, in handle_message
Mar 23 13:29:00  python[7309]:     await portal.handle_signal_message(user, sender, msg)
Mar 23 13:29:00  python[7309]:   File "/usr/lib/python3.9/site-packages/mautrix_signal/portal.py", line 422, in handle_signal_message
Mar 23 13:29:00  python[7309]:     content = await self._handle_signal_attachment(intent, attachment)
Mar 23 13:29:00  python[7309]:   File "/usr/lib/python3.9/site-packages/mautrix_signal/portal.py", line 481, in _handle_signal_attachment
Mar 23 13:29:00  python[7309]:     with open(attachment.incoming_filename, "rb") as file:
Mar 23 13:29:00  python[7309]: PermissionError: [Errno 13] Permission denied: '/var/lib/signald/attachments/***'

[celogeek]

Hi,

On arch with systemd:

You can stop signald do

systemctl edit signald
# put that:
[Unit]
User=mautrix-signal
Group=mautrix-signal

Then chown -R mautrix-signal: /var/lib/signald And start signald again

signald will start with the same user as mautrix-signal.

Replace mautrix-signal with the user you use to start mautrix-signal

[podiki]

Yes, that's exactly what I do. Are there other options or settings here or in signald instead? Not that this is a huge problem, but I'd expect to usually run different services (different packagers, signald at least could be used for other things) as different users and deal with permissions through a configuration or possible group permissions.

[olmari]

@podiki Well mautrix-signal and signald both needs to have access to certain files/folders (that are mentioned and defined in bridges config file) in order for things to play nicely in every aspect. How system admin achieves that is up to the person, some gives both users same UID/GID (and thus files are with same users then), some have more advanced ACLs in place...

Now in general I agree with you, but with this specific case separation doesn't bring that much of additional security, after all both knows pretty much everything about bridge users they're handling together anyways, so I've just done the same UID/GID for both signald and bridgebot system users...

[podiki]

@olmari I hear you. I'm not up on typical/best practices for this stuff, wondering what is cleaner. For Arch packages at least, I'd rather not have to edit the systemd service file and permissions of something created by signald on run. And it wouldn't make sense to package the bridge or signald to run as a user that doesn't make sense on its own. Perhaps in cases like this there should be a common shared folder with permissions based on a common group? So I guess as you say this can be set up by the admin to do that.

Regarding this issue then, I think it should be documented to check permissions or users for how you run signald (maybe in the sample config). Right now the documentation mentions configuring the homeserver settings and the bridge complaining if something is set wrong. In this case, however, it will silently fail to show images sent from Signal-->Matrix. The signalbot could report these errors at the very least.

Edit: I know there is something in the sample config about directories and being read by signald, but I don't think that addresses this issue.

[olmari]

I specifically gave/changed mautrix-signal system user (that I instated myself anyway) same UID/GID that signald has, signald was installed from debian backports repository. This way both still has even own separate home directories, while owner is same person (determined by the UID/GID, not by the textual username system happends to convert numerical ID into, which is either one from those 2 systemuser).

EDIT: This also allows the signald unitfile to say signald as user, while mautrix-signal unitfile can say mautrix-signal as user, both are "same user" as far as system is conserned (same numerical ID).

[podiki]

@olmari Thanks, probably the cleanest workaround.

Still, I would say this issue needs documentation (in config file or docs) and notification (signalbot reporting image not bridged and error). Otherwise I think it is a bit subtle, just missing images with no indication.

[jackal-87]

Since I also didn't want to mess with the systemd service file, my solution was to put the mautrix-signal user into the signald group. Then change the permission of /var/lib/signald to 775 and set the setGID-bit.

usermod -G signald mautrix-user
chmod 775 -R /var/lib/signald
chmod g+s /var/lib/signald

Now everything seems to work fine.

[celogeek]

Systemd has an override system that allows you to override partially the original configuration of a file.

The package config usually go to /usr/lib/systemd/system/myservice.service And when you edit a config: systemctl edit myservice Systemd create a file: /etc/systemd/system/myservice.service.d/override.conf

Then you can customize the launch. That is the whole point of systemd.

And systemctl status myservice show you where the file and the override files is.

You can even create other files yourself, like alarm.conf which contains a onFailure=... to be alerted in case of failure.

So systemd handle this properly, and you don't messup anything when you edit a config.

[jackal-87]

Ah cool, I didn't know that. I should look more into systemd. But when you do that, isn't it necessary to chown /var/lib/signald to that user?

[olmari]

But when you do that, isn't it necessary to chown /var/lib/signald to that user?

Yes.

[celogeek]

If you use pacman (Arch Linux for example), you can create a hooks with pacman to automatically set the permissing after an update. Also systemd can set the permission on the var/lib/signald like this:

[Unit]
User=mautrix-signal
Group=mautrix-signal
StateDirectory=signald
StateDirectoryMode=0750

You can also add a PreStart to fix the permission of the whole directory and subdirectory:

[Unit]
ExecStartPre=/usr/bin/chown -R mautrix-signal:mautrix-signal: /var/lib/signald

Or use systemd-tmpfile, so change the permission after an update or an install.

[celogeek]

It would be far better if mautrix-signal only use the API to get the attachment, and to remove them instead of going himself directly inside signald directory to pickup the file.

[olmari]

Best to do stuff so that constant fiddling isn't needed, while details how to achieve working system are endless :)

[olmari]

It would be far better if mautrix-signal only use the API to get the attachment, and to remove them instead of going himself directly inside signald directory to pickup the file.

mm.. well... as of now it is what it is, and mautrix-signal is build around that, which does involve filesystem level access to certain things.

[croxis]

I've started having a related issue. I'm running arch and both signald and mautrix-signald through AUR. I'm getting permission issues with the socket connection to signald, and I'm not enough of a systemd guru to figure it out.

### Editing /etc/systemd/system/signald.service.d/override.conf
### Anything between here and the comment below will become the new contents of the file

[Unit]
User=mautrix-signal
Group=mautrix-signal
StateDirectory=signald
StateDirectoryMode=0750

However my log for mautrix-signald is full of

[ERROR@mausignald] Connection to /var/run/signald/signald.sock failed: [Errno 13] Permission denied

and permissions

% sudo ls -la /var/run/signald
total 0
drwxrwx---  2 signald signald  60 Jul 16 23:09 .
drwxr-xr-x 28 root    root    700 Jul 16 23:08 ..
srw-rw-rw-  1 signald signald   0 Jul 16 23:09 signald.sock

Fixing /var/run/signald to 777 (I know, I know not a safe permission) fixed things.

[maltee1]

I've fixed this problem for myself by adding mautrix-signal to the signald group. This should be the cleanest approach, because it won't give signald access to mautrix-signal files, only the other way round. Changing the signald to the user mautrix-signal or vice versa is a mess in terms of automatic updates, making signald and mautrix-signal the same user seems like something that isn't supposed to be done. Every manual that required user A to have access to something of user B says to add user A to group B. So I don't think this is a bug, it's just something that should be included in the manuals.

[MayeulC]

Yes, there was previously an issue with signald where it wouldn't give r/w access to the group, that was fixed on 2021-08-20 https://gitlab.com/signald/signald/-/issues/205

The way mentioned above is now the cleanest.

[Follpvosten]

I think I might be having this problem with docker; any ideas for how to work around it there?

I use a custom user id and group id like this at the moment, so the data doesn't become unreadable for my host user.

environment:
  UID: 1000
  GID: 1000

[MayeulC]

@Follpvosten you did not give enough details for me to understand your setup.

What do you run inside docker? Mautrix? Signald? What runs as that UID? Mautrix? Signald? Are both in the same docker container? What are the permissions on the sock file? signald.sock? What about other signald files/folders (that mautrix needs to be able to read to process attachments, IIRC)?

[Follpvosten]

@MayeulC ok, most of that context should be in my compose file:

  mautrix-signal:
    image: dock.mau.dev/mautrix/signal:latest
    restart: unless-stopped
    volumes:
      - ./mautrix-signal:/data
      - ./signald:/signald
    environment:
      UID: 1000
      GID: 1000
    depends_on:
      - signald

  signald:
    image: docker.io/signald/signald
    restart: unless-stopped
    volumes:
      - ./signald:/signald

ls tells me that signald and all of its contents are chowned to 1337:1337.

$ ls -l signald
insgesamt 252
drwxr-x--- 2 1337 1337   4096 20. Apr 12:08 attachments
drwxr-xr-x 2 1337 1337   4096 15. Apr 00:25 avatars
drwxr-x--- 2 1337 1337   4096  6. Apr 19:20 data
-rw-r--r-- 1 1337 1337 245760 20. Apr 12:09 signald.db
srw-rw-rw- 1 1337 1337      0  6. Apr 19:20 signald.sock

apparently the signald container is doing the chown here. perhaps I need to make that one run as 1000:1000 as well; that would mean this is not a mautrix problem.

yep, confirmed that. setting user: 1000:1000 on the signald container seems to have fixed the issue for me. (the problem was largely due to my unusual setup; I set the ids to 1000:1000 for everything so I can easily access all the files as my normal user.)