- Arch-general - lists.archlinux.org

[arch-general] matrix-synapse "enhanced" security
by Uwe Sauter 18 Nov '21

18 Nov '21

Dear all, beginning with matrix-synapse 1.44.0-1 in early October a Systemd override file (see below for reference) was included to the package that aims to enhance the security of Synapse. Amongst other things it tells Systemd to restrict access to certain directories that are seen as defaults. Unfortunately this enhancement broke my setup by neglecting that there are various paths inside Synapse's configuration that can be customized, e.g. media_store_path and uploads_path. The error I see in my logs is: 2021-11-18 19:54:30,772 - synapse.rest.media.v1.preview_url_resource - 559 - WARNING - expire_url_cache_data-1281 - Failed to remove media directory: '/srv/matrix/media_store/url_cache/2021-10-08': [Errno 30] Read-only file system: '/srv/matrix/media_store/url_cache/2021-10-08' 2021-11-18 19:54:30,774 - synapse.rest.media.v1.preview_url_resource - 617 - WARNING - expire_url_cache_data-1281 - Failed to remove media: '2021-10-08_cgWYZUYMTRBdzskW': [Errno 30] Read-only file system: '800-450-image-jpeg-scale' It is also impossible to insert pictures into the chat. The client just tells "unable to send message" but no log entry is created on the server. Did I miss any notification about this change? Can anyone help me with customizing the Systemd override file so that Synapse regains access to media_store_path and uploads_path? Any help is appreciated. Thank you, Uwe ### /usr/lib/systemd/system/synapse.service.d/override-hardened.conf ### [Service] # The following directives give the synapse service R/W access to: # - /run/synapse # - /var/lib/synapse # - /var/log/synapse RuntimeDirectory=synapse StateDirectory=synapse LogsDirectory=synapse ###################### ## Security Sandbox ## ###################### # Make sure that the service has its own unshared tmpfs at /tmp and that it # cannot see or change any real devices PrivateTmp=true PrivateDevices=true # We give no capabilities to a service by default CapabilityBoundingSet= AmbientCapabilities= # Protect the following from modification: # - The entire filesystem # - sysctl settings and loaded kernel modules # - No modifications allowed to Control Groups # - Hostname # - System Clock ProtectSystem=strict ProtectKernelTunables=true ProtectKernelModules=true ProtectControlGroups=true ProtectClock=true ProtectHostname=true # Prevent access to the following: # - /home directory # - Kernel logs ProtectHome=tmpfs ProtectKernelLogs=true # Make sure that the process can only see PIDs and process details of itself, # and the second option disables seeing details of things like system load and # I/O etc ProtectProc=invisible ProcSubset=pid # While not needed, we set these options explicitly # - This process has been given access to the host network # - It can also communicate with any IP Address PrivateNetwork=false RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX IPAddressAllow=any # Restrict system calls to a sane bunch SystemCallArchitectures=native SystemCallFilter=@system-service SystemCallFilter=~@privileged @resources @obsolete # Misc restrictions # - Since the process is a python process it needs to be able to write and # execute memory regions, so we set MemoryDenyWriteExecute to false RestrictSUIDSGID=true RemoveIPC=true NoNewPrivileges=true RestrictRealtime=true RestrictNamespaces=true LockPersonality=true PrivateUsers=true MemoryDenyWriteExecute=false ### EOF ###

3 4

[arch-general] Brothers, did you see Edward Snowden mentioned our wiki? Huzzah
by Yosef Goldstein 18 Nov '21

18 Nov '21

https://mobile.twitter.com/Snowden/status/1460666075033575425

2 1

[arch-general] Why no option to stay with clamav 103 since as a LTS release it will be supported longer then 104?
by David C. Rankin 17 Nov '21

17 Nov '21

All, Just curious why Arch doesn't also provide the option to track clamav_LTS which will stay with 103 and will be supported much longer than 104? I know, I know, Arch matches upstream, but when upstream provides both current and LTS, wouldn't it make sense to also package and provide LTS like with the kernel? (the packaging would be trivial and the same between the current and LTS aside from the source package for all purposes) Just a thought as there is real advantage to being able to track the clamav LTS release here, without hacking pacman.conf. There are few packages that actually provide a LTS branch so it wouldn't open the flood gates to a bevy of new packages. -- David C. Rankin, J.D.,P.E.

3 3

[arch-general] IOMMU spam with kernel 5.15.2.arch1-1 when starting VM
by jk 14 Nov '21

14 Nov '21

Hello, after the recent linux kernel update I started to get a lot of errors on dmesg when starting a virtual machine, I'm passing through a gpu to it. The gist of the error spam is this [ +0.000001] DMAR: ERROR: DMA PTE for vPFN 0x813ee8 already set (to 105eff003 not 105eff003) [ +0.000002] ------------[ cut here ]------------ [ +0.000001] WARNING: CPU: 8 PID: 1960 at drivers/iommu/intel/iommu.c:2381 __domain_mapping.cold+0x32/0x39 [ +0.000001] Modules linked in: vhost_net vhost vhost_iotlb tap tun wireguard curve25519_x86_64 libchacha20poly1305 chacha_x86_64 poly1305_x86_64 libblake2s blake2s_x86_64 libcurve25519_generic libchacha libblake2s_generic ip6_udp_tunnel udp_tunnel bridge stp llc nft_masq nft_chain_nat nf_nat nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_counter nft_limit nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink nct6775 hwmon_vid snd_hda_codec_realtek snd_hda_codec_generic intel_rapl_msr iTCO_wdt intel_pmc_bxt mei_hdcp ee1004 iTCO_vendor_support wmi_bmof snd_sof_pci_intel_tgl snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda intel_rapl_common mousedev snd_sof_pci snd_usb_audio snd_sof_xtensa_dsp snd_sof snd_usbmidi_lib x86_pkg_temp_thermal joydev snd_soc_hdac_hda intel_powerclamp snd_rawmidi coretemp snd_hda_ext_core snd_soc_acpi_intel_match snd_seq_device mc snd_soc_acpi kvm_intel soundwire_bus [ +0.000017] ledtrig_audio kvm snd_soc_core intel_cstate snd_compress intel_spi_pci amdgpu intel_spi intel_uncore pcspkr ac97_bus snd_hda_codec_hdmi spi_nor snd_pcm_dmaengine mtd snd_hda_intel i2c_i801 snd_intel_dspcfg i2c_smbus r8169 snd_intel_sdw_acpi snd_hda_codec realtek mei_me mdio_devres snd_hda_core gpu_sched libphy mei nouveau snd_hwdep snd_pcm snd_timer snd soundcore mxm_wmi vfat drm_ttm_helper wmi fat mac_hid acpi_pad acpi_tad kvmfr(OE) fuse ip_tables x_tables ext4 crc16 mbcache jbd2 usbhid dm_thin_pool dm_persistent_data libcrc32c crc32c_generic dm_bio_prison dm_bufio dm_crypt cbc encrypted_keys trusted asn1_encoder tee i915 crct10dif_pclmul crc32_pclmul dm_mod crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd tpm_crb cryptd intel_gtt xhci_pci ttm xhci_pci_renesas tpm_tis tpm_tis_core tpm rng_core video vfio_pci vfio_pci_core irqbypass vfio_virqfd vfio_iommu_type1 vfio [ +0.000020] CPU: 8 PID: 1960 Comm: CPU 6/KVM Tainted: G U W OE 5.15.2-arch1-1 #1 e3bfbeb633edc604ba956e06f24d5659e31c294f [ +0.000001] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z590 Steel Legend, BIOS P1.80 07/22/2021 [ +0.000000] RIP: 0010:__domain_mapping.cold+0x32/0x39 [ +0.000001] Code: f6 48 c7 c7 80 0f af a0 4c 89 54 24 08 e8 e8 aa fd ff 8b 05 49 b1 1d 01 4c 8b 54 24 08 85 c0 74 09 83 e8 01 89 05 37 b1 1d 01 <0f> 0b e9 2f a5 b8 ff 4c 89 c9 44 89 da 48 c7 c6 30 32 74 a0 48 c7 [ +0.000000] RSP: 0018:ffffb32ac27dfbf0 EFLAGS: 00010246 [ +0.000001] RAX: 0000000000000000 RBX: ffff972a598b5740 RCX: 0000000000000000 [ +0.000000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ +0.000001] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 [ +0.000000] R10: ffff972a02213700 R11: 0000000000000000 R12: ffff972a02213700 [ +0.000001] R13: 0000000000105eff R14: 0000000000813ee8 R15: 0000000105eff003 [ +0.000000] FS: 00007f1f699ff640(0000) GS:ffff97313fc00000(0000) knlGS:0000000000000000 [ +0.000001] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000001] CR2: 00007f1f51bab000 CR3: 000000018a69a002 CR4: 0000000000772ee0 [ +0.000000] PKRU: 55555554 [ +0.000000] Call Trace: [ +0.000001] intel_iommu_map_pages+0xb0/0x100 [ +0.000002] __iommu_map+0xde/0x2c0 [ +0.000001] iommu_map+0x41/0x80 [ +0.000001] vfio_iommu_type1_ioctl+0x85f/0x1670 [vfio_iommu_type1 1ddc5c5dceb1dace15f0dee1b2f809fe6662c7c4] [ +0.000003] __x64_sys_ioctl+0x8b/0xd0 [ +0.000001] do_syscall_64+0x59/0x90 [ +0.000002] ? do_user_addr_fault+0x20b/0x6b0 [ +0.000002] ? exc_page_fault+0x72/0x180 [ +0.000000] entry_SYSCALL_64_after_hwframe+0x44/0xae [ +0.000002] RIP: 0033:0x7f218b9d559b [ +0.000000] Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a5 a8 0c 00 f7 d8 64 89 01 48 [ +0.000001] RSP: 002b:00007f1f699fdfa8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ +0.000000] RAX: ffffffffffffffda RBX: 000055d7a02181d0 RCX: 00007f218b9d559b [ +0.000001] RDX: 00007f1f699fdfb0 RSI: 0000000000003b71 RDI: 000000000000002b [ +0.000000] RBP: 0000000812000000 R08: 0000000000000000 R09: 0000000006000000 [ +0.000001] R10: 0000000812000000 R11: 0000000000000246 R12: 0000000002000000 [ +0.000000] R13: 0000000812000000 R14: 00007f1f699fdfb0 R15: 0000000000000000 Here's the full dmesg log, too big for pasting sites: https://cloud.vin.ovh/s/3TpSgCgYs9oq9jY I started to look around for this error messages and found the following mailing list. https://www.spinics.net/lists/kernel/msg4097048.html First it proposed a patch to silence those error messages as they aren't lethal but after some research another patch was proposed which actually solved the issue I think. https://lists.linuxfoundation.org/pipermail/iommu/2021-October/059955.html It is quite small and it seems that it didn't get the required attention. I added the patch to the linux PKGBUILD and the errors no longer appear. Is there a possibility to add that patch to the linux package? Don't really want to build the kernel every time it is updated.

3 3

[arch-general] Should PacBSD (Arch with BSD kernel) be revived?
by KSP Atlas 13 Nov '21

13 Nov '21

PacBSD is a GNU/BSD distribution of Arch Linux but with the BSD kernel instead. Do you think it should be revived, as it seems to be dead with the website down and everything?

1 0

[arch-general] New LXQt (1.0.0) with big text size, affecting other Qt apps
by Javier 12 Nov '21

12 Nov '21

Hello ! I've been using LXQt for some time now (years), and with Today's Arch upgrade, which included a LXQt upgrade 0.17.0-1 -> 1.0.0-1, everything was showing app really big, from LXQt own text (menus, icons, widgets, etc) to other apps. The only work around I found was to reduce the font size on LXQt's preferences, and also on Qterminal, I had to change it from like 18 to 10 on Qterminal, and from 16 to 10 on LXQt itself. I still see other apps bigger than what they used to be, and in particular the apps' toolbar became wider, and the border surrounding Qt apps became wider (to the point it's annoying). It's not about manipulating QT_SCALE_FACTOR + QT_AUTO_SCREEN_SCALE_FACTOR, and the like, because that's to make things bigger when they look way to small and unreadable. Actually by setting QT_SCALE_FACTOR to 1, its the same behavior as not setting any variable, and lower than 0 values don't really work on Qt (I tried, and the results are really weird, non functional to say the least). Have other lxqt users experienced the same on Arch? Would it be an Arch building and packaging issue? Or this is totally an upstream thing? Thanks ! -- Javier

9 13

Re: [arch-general] gpg-agent Failed to lookup
by José Vilmar Estácio de Souza 11 Nov '21

11 Nov '21

Hi Keith, It worked for me too, although I have no idea of the possible implications either. Thank you very much. On 11/9/21 12:19, Keith Scheiwiller wrote: > Hi José, > > I just ran into what I assume is the same issue yesterday. > > After digging around I found [this][1] seemingly similar bug report. > I found that the binary provided in the package does indeed have > additional capabilities set. > ``` > $ getcap /usr/bin/gnome-keyring-daemon > /usr/bin/gnome-keyring-daemon cap_ipc_lock=ep > ``` > > As I was in a bit of a rush I did a quick > `$ sudo setcap -r /usr/bin/gnome-keyring-daemon` > and found that it began working as expected. > Of course I would not recommend doing so as I do not know the > implications of removing that, but hopefully someone more > knowledgeable can chime in with more info. I see others on the > forum possibly having the same issues. > > [1]: <https://gitlab.gnome.org/GNOME/glib/-/issues/2518> > > Regards, > Keith > > > On Tue, Nov 9, 2021 at 8:49 AM José Vilmar Estácio de Souza via > arch-general <arch-general(a)lists.archlinux.org> wrote: > > Hi all. > > > After recent updates to arch I started having problems with some > programs that make use of the gnome-keyring-daemon. > > When I run for example the command 'pass -c git-azure', the command > takes about 15 seconds to ask for the password and the following > messages appear in the log: > > > Nov 09 11:13:26 jveii gpg-agent[124433]: Failed to lookup password > for > key n/1128A1F67CEF113D23CE021A5502F13DEE17610C with secret service: > Error calling StartServiceByName for org.freedesktop.secrets: Timeout > was reached > Nov 09 11:13:01 jveii gnome-keyring-d[124438]: Couldn't connect to > session bus: Cannot spawn a message bus when setuid > Nov 09 11:13:01 jveii gnome-keyring-daemon[124438]: Couldn't > connect to > session bus: Cannot spawn a message bus when setuid > Nov 09 11:13:01 jveii /usr/lib/gdm-x-session[124438]: > SSH_AUTH_SOCK=/run/user/1000/keyring/sshNov 09 11:13:01 jveii > gnome-keyring-daemon[783]: couldn't connect to dbus session bus: > Cannot > spawn a message bus when setuid > Nov 09 11:13:01 jveii /usr/lib/gdm-x-session[795]: dbus-daemon[795]: > [session uid=1000 pid=795] Activating service > name='org.freedesktop.secrets' requested by ':1.1451' (uid=1000 > pid=124433 comm="/usr/bin/pinentry-gtk-2 --display :0 ") > > > I'm also having issues with other applications like vpn > connections and > chromium is taking a while to display the first page once it > starts up. > > > Does anyone have any idea what I might be doing wrong? > > Thank you very much in advance. >

1 0

[arch-general] Introduction
by Yosef Goldstein 11 Nov '21

11 Nov '21

Hi everyone I am Yosef from Israel. I am excited to be part of the Arch community.

3 2

[arch-general] gpg-agent Failed to lookup
by José Vilmar Estácio de Souza 09 Nov '21

09 Nov '21

Hi all. After recent updates to arch I started having problems with some programs that make use of the gnome-keyring-daemon. When I run for example the command 'pass -c git-azure', the command takes about 15 seconds to ask for the password and the following messages appear in the log: Nov 09 11:13:26 jveii gpg-agent[124433]: Failed to lookup password for key n/1128A1F67CEF113D23CE021A5502F13DEE17610C with secret service: Error calling StartServiceByName for org.freedesktop.secrets: Timeout was reached Nov 09 11:13:01 jveii gnome-keyring-d[124438]: Couldn't connect to session bus: Cannot spawn a message bus when setuid Nov 09 11:13:01 jveii gnome-keyring-daemon[124438]: Couldn't connect to session bus: Cannot spawn a message bus when setuid Nov 09 11:13:01 jveii /usr/lib/gdm-x-session[124438]: SSH_AUTH_SOCK=/run/user/1000/keyring/sshNov 09 11:13:01 jveii gnome-keyring-daemon[783]: couldn't connect to dbus session bus: Cannot spawn a message bus when setuid Nov 09 11:13:01 jveii /usr/lib/gdm-x-session[795]: dbus-daemon[795]: [session uid=1000 pid=795] Activating service name='org.freedesktop.secrets' requested by ':1.1451' (uid=1000 pid=124433 comm="/usr/bin/pinentry-gtk-2 --display :0 ") I'm also having issues with other applications like vpn connections and chromium is taking a while to display the first page once it starts up. Does anyone have any idea what I might be doing wrong? Thank you very much in advance.

2 1

[arch-general] Really about tty !
by Philippe Delavalade 09 Nov '21

09 Nov '21

Hi. By default, six ttys are defined but I would have more ; in distros with sysv there was an /etc/inttab file defining consoles and it was simple to define more. I didn't find info in the wiki ; I pretty sure my method to search is bad but... Regards. -- Philippe

3 3