/boot/dietpi/func/dietpi-logclear 1 => /boot/dietpi/func/dietpi-logclear: line 126: /var/log/postgresql/postgresql-15-main.log: Permission denied

Creating a bug report/issue

Required Information

  • DietPi version | cat /boot/dietpi/.version 8.19.1 (master, owner: MichaIng, G_LIVE_PATCH_STATUS=[applied,applied,not applied]
  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN bookworm 0
  • Kernel version | uname -a Linux DietPi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
  • Architecture | dpkg --print-architecture arm64
  • SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3) RPi 3 Model B+ (aarch64)
  • Power supply used | (EG: 5V 1A RAVpower) 5V DC 3A
  • SD card used | (EG: SanDisk ultra) SanDisk Extreme 32GB

Steps to reproduce

  1. apt update && apt install -y postgresql
  2. /boot/dietpi/func/dietpi-logclear 1

Expected behaviour

Not run into a Permission denied error.

Actual behaviour

root@dietpi:~# /boot/dietpi/func/dietpi-logclear 1
/boot/dietpi/func/dietpi-logclear: line 126: /var/log/postgresql/postgresql-15-main.log: Permission denied
[ INFO ] DietPi-Logclear | Summary:
 - Log file directory      | /var/log
 - Processed files         | 12
 - Cleared log files       | 3
 - Unsupported files       | 0
 - Deleted files           | 0
 - Space cleared           | 346 KiB

Extra details

I actually wouldn’t mind if /var/log is kept clean by logrotate. I don’t need to save space.

Deleting /etc/cron.hourly/dietpi does not seem like a great idea as it handles other stuff as well.
Is there a way to disable the “DietPi Logrotation/deletetion”? I don’t really have disk space issues, so I’d be glad to have some more logs anyways.

1 Like

You can switch to permanent logging and then config logrotate to keep as many logs as you want.


Ty for the link. I now understand the motivation for the approach : D.

In that case: Why is dietpi-logclear not permitted to clear postgresql logs? Shouldn’t it run as root?..

I did stop the postgresql service and tested it again in case it locked the file. But still getting the permission denied error.

NOTE: postgresql is installed via apt.

It is not installed via our software catalogue?

Nope. The reason why is that I stopped trusting it recently when I removed one via dietpi-software and it removed the software/package data as well (from /mnt/dietpi_data/…). Which I found ridiculous without warning. Luckily I was just experimenting. Kind of disliked it and would prefer the PKG MGR way where I know how things work.

I guess this is what DietPi does when installing postgresql, right?

I don’t see anything that could be related to the “permission denied” error (nothing that would prevent it).

just checked on a demo system and the behaviour is the same. Maybe PostgreSQL has changed something. @MichaIng can you remember if the behaviour was always like this?

It’s due to the sticky bit on the /var/log/postgresql directory.

To “fix”:

chmod o-t /var/log/postgresql

Works the same for /tmp directory:

timoses@dietpi:~$ touch test
timoses@dietpi:~$ sudo bash -c "> /tmp/test"
bash: line 1: /tmp/test: Permission denied

I wonder if there would be a better way…

Some more info:

Tested this a bit:

timoses@dietpi:~$ sudo sysctl fs.protected_regular
fs.protected_regular = 2
timoses@dietpi:~$ sudo sysctl fs.protected_regular=1
fs.protected_regular = 1
# This works now, because it is a non-world(/other) writeable directory 
timoses@dietpi:~$ sudo bash -c "> /var/log/postgresql/postgresql-15-main.log"
# This fails, because `/tmp` is a world-writable directory
timoses@dietpi:~$ sudo bash -c "> /tmp/test"
bash: line 1: /tmp/test: Permission denied
timoses@dietpi:~$ sudo sysctl fs.protected_regular=0
fs.protected_regular = 0
timoses@dietpi:~$ sudo bash -c "> /tmp/test"
timoses@dietpi:~$ sudo sysctl fs.protected_regular=2
fs.protected_regular = 2
timoses@dietpi:~$ sudo bash -c "> /var/log/postgresql/postgresql-15-main.log"
bash: line 1: /var/log/postgresql/postgresql-15-main.log: Permission denied

In general this seems to be newly set in Bullseye (NewInBullseye - Debian Wiki):

systemd now enables the fs.protected_fifos and fs.protected_regular kernel parameters by default. This may break applications that share files in /tmp (or other sticky directories) among multiple user accounts. The protection may be disabled temporarily by running sysctl fs.protected_regular=0 and sysctl fs.protected_fifos=0 or permanently by creating a file with a name ending in .conf in the /etc/sysctl.d directory

Not sure what the security implications would be, if one sets fs.protected_regular=1.

Another possibility: Use truncate

truncate -c -s0 /var/log/postgresql/postgresql-15-main.log

=> Works!
I suspect the -c is required in order to not trigger the O_CREAT. Without -c it fails.

@MichaIng : Do you think it would be an idea to replace >$i with truncate -c -s0 $1?

Created a PR: Fix dietpi-logclear failing on files in sticky bit directories by Timoses · Pull Request #6507 · MichaIng/DietPi · GitHub



1 Like