BW CLI crashes when started through an UDEV rule

[tra0815]

Steps To Reproduce

Have an udev rule which starts a script like: ......, RUN+="/root/bw" The script contains a bw call like 'bw list items'. #!/bin/bash
export BW_SESSION=[put session here]
V=$(/snap/bin/bw list items 2>&1)
echo $V
The script runs fine when called in terminal, it runs fine when called in a cron job, but it crashes, when started like described.

Expected Result

It runs and shows the same output when started in a terminal.

Actual Result

dmesg shows following error:
traps: bw[2737087] trap int3 ip:ebf052 sp:7ffd58e11300 error:0 in bw[91c000+167b000]

When redirecting or mailing the $V from the script, it shows: <--- Last few GCs ---> <--- JS stacktrace ---> # # Fatal javascript OOM in MemoryChunk allocation failed during deserialization. #

Screenshots or Videos

No response

Additional Context

No response

Operating System

Linux

Operating System Version

Debian Bookworm, 6.1.0-17-amd64

Shell

Bash

Build Version

2024.1.0

Issue Tracking Info

• [X] I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[sso-bitwarden]

Thank you for your report. I could reproduce the issue. The engineering team will review the issue further.

[septatrix]

You are likely better of defining a systemd service and pulling that in via the SYSTEMD_WANTS property. As the man pages say the processes spawned during udev event handling are very limited in what they can do:

This can only be used for very short-running foreground tasks. Running an event process for a long period of time may block all further events for this or a dependent device.

Note that running programs that access the network or mount/unmount filesystems is not allowed inside of udev rules, due to the default sandbox that is enforced on systemd-udevd.service.

Starting daemons or other long-running processes is not allowed; the forked processes, detached or not, will be unconditionally killed after the event handling has finished. In order to activate long-running processes from udev rules, provide a service unit and pull it in from a udev device using the SYSTEMD_WANTS device property. See systemd.device(5) for details.