7 Commits

Author SHA1 Message Date
Sunil Mohan Adapa
529bbf77df
bepasty: Don't remove old system user and group
As removing a system user and group is considered a bad practice.  Old unused
system accounts are mostly harmless.

Tests:

- Bepasty functional tests pass.

- Installing bepasty and uploading a file works.

Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
2026-05-13 15:37:38 -07:00
James Valleroy
0e698eb4b4
apache: Use a Uwsgi native socket systemd unit for each app
[Sunil]:

- Drop Uwsgi component entirely. After the changes, it mostly looks like Daemon
component minus some features. One change that Uwsgi component does is when
component is disabled, it also stops and disables the .service unit. Stopping
the service is useful and we can add this to Daemon component.

- Use /run instead of /var/run/ as 1) /var/run is a symlink to /run 2) /run/
path is what is listed in uwsgi-app@.socket unit file.

- Implement upgrade for apps from older version. Disable and mask uwsgi init.d
script. Enable the daemon component if the webserver component is enabled.

- Update manifest files to deal with .socket units instead of 'uwsgi' service.
Backup the /var/lib/private directories as that is actual directory to backup
with DynamicUser=yes.

- For bepasty load the configuration as a systemd provided credential since
DynamicUser=yes.

- Remove the /var/lib/private directories during uninstall.

- Don't create user/group for bepasty as it is not needed with DynamicUser=yes.

Tests:

- Radicale

  - Functional tests pass

  - Freshly install radicale.

  - Web interface works.

  - Create and edit calendars

  - Path of the storage directory is in /var/lib/private/radicale (after
  accessing web interface)

  - Permissions on the storage folder and files inside are set to nobody:nobody.

  - Uninstall removes the /var/lib/private/radicale directory.

  - Create a calender and backup the app. Uninstall the app. Re-install the app.
  The calendar is not available. After restoring the backup, the calendar is
  available.

  - Install radicale without patch and create a calendar. Apply patches and
  start plinth.service. Setup is run. UWSGI is disabled and masked. Service is
  running. Old calender is visible.

  - Install radicale without patch. Disable and apply patches and start
  plinth.service. Setup is run. UWSGI is disabled and masked. Service is not
  running. Enabling the service works.

  - After upgrade, data storage path got migrated to /var/lib/private/radicale.
  Old data is accessible.

  - After upgrade the directory is still owned by radicale:radicale.

  - Freshly install radicale with patch and restore an old backup. The data is
  available in the web interface and data was migrated to
  /var/lib/private/radicale.

- Bepasty

  - Functional tests pass

  - Freshly install bepasy.

  - Enabling and disabling rapidly works.

  - Uploading files works.

  - Path of the storage directory is /var/lib/private/bepasty.

  - Permissions on the storage folder are as expect 755 but on the parent are
  700.

  - Permissions on the stored files are 644 and owned by nobody:nobody.

  - Uninstall removes the /var/lib/private/bepasty directory.

  - Upload a picture and backup the app. Uninstall the app. Re-install the app.
  The uploaded file is not available. After restoring the backup, the uploaded
  file is available.

  - Install bepasty without patch and upload a file. Apply patches and start
  plinth.service. Setup is run. UWSGI is disabled and masked. Service is
  running. Old uploaded picture is visible.

  - Install bepasty without patch. Disable app. Apply patches and start
  plinth.service. Setup is run. UWSGI is disabled and masked. Service is not
  running. Enabling the service works.

  - After upgrade, data storage path got migrated to /var/lib/private/bepasty.
  Old data is accessible.

  - After upgrade the directory is still owned by bepasty:bepasty.

  - Freshly install bepasty with patch and restore an old backup. The uploaded
  file is available in the web interface and data was migrated to
  /var/lib/private/bepasty.

Signed-off-by: James Valleroy <jvalleroy@mailbox.org>
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
2026-03-21 07:45:51 -07:00
Sunil Mohan Adapa
61ff15a04f
*: Use action_utils.run instead of subprocess.run
- This is to capture stdout and stderr and transmit that from privileged daemon
back to the service to be displayed in HTML.

Tests:

- Unit tests and code checks pass.

- Some of the modified actions work as expected.

Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
2025-09-29 16:58:53 +03:00
Sunil Mohan Adapa
d900b2c9b1
bepasty: Mark secret strings in privileged actions
Tests:

- Perform effected actions and ensure that secrets are not logged on the
console.

Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
2024-08-11 12:57:22 -04:00
Sunil Mohan Adapa
38ece87c6c
*: Utilize newer 3.10 syntax for type hints
Tests:

- mypy does not show any errors.

- Installing ejabberd app works. Privileged actions run fine.

- Unit tests work.

- No additional testing was done as type annotations don't have any effect at
runtime.

Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
2023-09-25 20:03:34 -04:00
nbenedek
3d71869211
bepasty: Completely uninstall app
During the uninstall process:

* Remove bepasty data directory
* Remove freedombox config file
* Remove bepasty user (and group)

Test:

* Manually test if data is indeed removed
* Run functional tests

Signed-off-by: nbenedek <contact@nbenedek.me>
[sunil: Update docstrings, make uninstall fail-safe]
[sunil: Remove bapasty group as well]
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
2023-04-11 09:58:57 +05:30
Sunil Mohan Adapa
212364ba2a
bepasty: Use privileged decorator for actions
Tests:

- Functional tests
- Initial setup
  - Sets the domain to freedombox.local (SITENAME)
  - Default permissions are set to read
  - Three passwords with varying permissions are create by default
- Current configuration is retrieved properly (default permissions, passwords)
- Adding passwords works, they are list as expected
  - With or without comment
- Removing password works
- Setting default permissions works
- Untested:
  - Upgrade from version 1

Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
2022-10-08 18:51:18 -04:00