| View previous topic :: View next topic |
| Author |
Message |
ManDay
Apprentice
Joined: 22 Jan 2008
Posts: 247
|
 Posted: Wed Apr 20, 2022 8:37 am Post subject: [SOLVED] user's file on tmpfs is denied for root |
 |
|
Hi,
portage has recently started complaining that PermissionError: [Errno 13] Permission denied: b'/var/log/emerge-fetch.log' and [Errno 13] Permission denied: b'/var/log/emerge.log' where especially the former (emerge-fetch.log) turned out to be fatal in some circumstances, whereas I was still able to do some emerging despite the latter (emerge.log) showing up all over the place.
/var/log is a tmpfs on my box, so while investigating the problem, I have come down to find that running the following commands as root
| Code: | | # mkdir test ; mount -t tmpfs -o size=10M none test ; touch test/x ; chmod 777 test/x ; chown portage:portage test/x ; echo x >> test/x |
(in other words: writing to a file on a tmpfs which is owned by a user) leads to the error -bash: test/x: Permission denied. At the current time, I'm unable to say whether that is the cause for my problem with portage, but it is as far as I could get with my investigation - and now I don't know what to make of this.
I have used this setup (/var/log, besides a few other directories, being tmpfs) for a long time without problems, and although I never bothered to check for this peculiar behaviour of a tmpfs before, I suspect it to be the cause - but I don't understand why it started so spontaneously, since I did not change any configuration.
A workaround would of course be to get rid of all my tmpfs, but I hope you can help me to solve this differently.
Thanks!
(edit: added `chmod` to the command to illustrate that the mode does not help)
Last edited by ManDay on Wed Apr 20, 2022 9:06 am; edited 1 time in total |
|
| Back to top |
|
 |
ManDay
Apprentice
Joined: 22 Jan 2008
Posts: 247
|
| Posted: Wed Apr 20, 2022 9:03 am Post subject: |
|
|
Thanks to the fellow users on IRC, esp. username234 who came up with the idea, we found that removing the sticky bit (which appears on /var/log due to the tmpfs mount) and causes the behaviour due to "sysctl fs.protected_regular=1" (thanks grawity) will fix the problem.
Still unclear why this has started becoming a problem so suddenly, it looks like fs.protected_regular has been 0 when it worked. |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2892
|
| Posted: Wed Apr 20, 2022 9:14 am Post subject: |
|
|
| ManDay wrote: | | Still unclear why this has started becoming a problem so suddenly, it looks like fs.protected_regular has been 0 when it worked. |
cross-posting from IRC for reference: https://bugs.gentoo.org/834085
(for systemd users the above likely changed nothing, it was already a default through a .conf file -- well, beside allowing it to be active from the get-go) |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23088
|
| Posted: Wed Apr 20, 2022 3:50 pm Post subject: |
|
|
| Removing the sticky bit alone is not the right solution, in my opinion. You should instead arrange for the tmpfs mounted at /var/log to have the same owner, group, and permissions as the non-tmpfs directory /var/log used by most systems. For me, that means root:root 755. I suspect from your post that you have 777 and no sticky bit, which is a bad combination. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
