1 |
Greetings, |
2 |
|
3 |
On Wednesday, 2022-03-09 19:28:49 +0100, I myself wrote: |
4 |
|
5 |
> ... |
6 |
> until recently my system behaves sort of strangely: |
7 |
> |
8 |
> $ touch /tmp/file |
9 |
> $ ls -l /tmp/file |
10 |
> -rw------- 1 rainer rainer 0 2022-03-09 19:06 /tmp/file |
11 |
> $ echo x | sudo tee /tmp/file |
12 |
> Password: |
13 |
> tee: /tmp/file: Permission denied |
14 |
> x |
15 |
> $ chmod a+w /tmp/file |
16 |
> $ ls -l /tmp/file |
17 |
> -rw--w--w- 1 rainer rainer 0 2022-03-09 19:06 /tmp/file |
18 |
> $ echo x | sudo tee /tmp/file |
19 |
> tee: /tmp/file: Permission denied |
20 |
> x |
21 |
> $ |
22 |
> |
23 |
> Since when can't root write to files it doesn't own? And not even, if |
24 |
> the file has write permission for everybody? |
25 |
|
26 |
Turns out it's not a bug but a feature, more precisely a security feat- |
27 |
ure. Its purpose is to prevent an unprivileged local user from luring |
28 |
user "root" into writing possibly sensitive information to an already |
29 |
existing file owned by and thus accessible to the local attacker. |
30 |
|
31 |
This protection feature was introduced as an option deactivated by def- |
32 |
ault way back in some 4.* kernel, and somewhere between kernels 5.15.19 |
33 |
and 5.15.26 the default was changed to on. |
34 |
|
35 |
If you want or have to, you can again disable this feature at runtime |
36 |
using |
37 |
|
38 |
# sysctl fs.protected_regular=0 |
39 |
|
40 |
or permanently from the next boot onwards via |
41 |
|
42 |
# echo fs.protected_regular = 0 >> /etc/sysctl.d/local.conf |
43 |
|
44 |
Personally, I've decided to again boot kernel 5.15.26, to leave the new |
45 |
default setting (even on my laptop), and to adapt my script which had |
46 |
problems with this new behaviour accordingly. |
47 |
|
48 |
Your milage may vary. |
49 |
|
50 |
Sincerely, |
51 |
Rainer |