I have a file /var/spool/mail/dummy which I want to empty every night.
Ever since I upgraded to Mga7 my cron has not worked. It does
> /var/spool/mail/dummy
which should empty the file. But it no longer worked. Instead a get a
"does not have permission" error message. lsattr shows no extended
attributes set.
The file is in a directory mounted from an encrypted filesystem.

The file originally had rw_rw_r__ permisisons. I changed it to rw_______
but that made no difference.

What could be going on here?


--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On Wed, 11 Mar 2020 04:25:55 -0000 (UTC), William Unruh wrote:

I have a file /var/spool/mail/dummy which I want to empty every night.
Ever since I upgraded to Mga7 my cron has not worked. It does
> /var/spool/mail/dummy
which should empty the file. But it no longer worked. Instead a get a
"does not have permission" error message. lsattr shows no extended
attributes set.

The file originally had rw_rw_r__ permisisons. I changed it to rw_______
but that made no difference.

What could be going on here?

No idea here; no useful information provided. For example:
Who's cron job (root, user)?
Vaid UID:GID?
actual error message is?
Actual copy of script doing the work?


Personally, as an old maintenance programmer I prefer code which is
readable at a glance by anyone. As example I would have used
truncate -s 0 /var/spool/mail/dummy
rather than having to check the previous line to see if there was/needs
a trailing \.

The file is in a directory mounted from an encrypted filesystem.

Going to make a wild ass guess, problem will be result of the above
and a gotcha as a result of changing nfs mount changes in recent past. :)





--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On 2020-03-11, Bit Twister <BitTwister@mouse-potato.com> wrote:

On Wed, 11 Mar 2020 04:25:55 -0000 (UTC), William Unruh wrote:

I have a file /var/spool/mail/dummy which I want to empty every night.
Ever since I upgraded to Mga7 my cron has not worked. It does
> /var/spool/mail/dummy
which should empty the file. But it no longer worked. Instead a get a
"does not have permission" error message. lsattr shows no extended
attributes set.

bash: /var/spool/mail/dummy: Permission denied

That was also what I got if I did

/var/spool/mail/dummy

as root from a terminal, and from that cron running as root.

If I did vi /var/spool/mail/dummy, I could read it.

Permissions on /var/spool/mail/dummy were
rw_rw_r__ root root

I finally got tired of investigating and did
rm /var/spool/mail/dummy
as root, and then
touch /var/spool/mail/dummy
and now

/var/spool/mail/dummy

worked without error

So it becomes "What the hell happened?" and not
"How can I fix this"

The file originally had rw_rw_r__ permisisons. I changed it to rw_______
but that made no difference.

What could be going on here?

No idea here; no useful information provided. For example:
Who's cron job (root, user)?
Vaid UID:GID?
actual error message is?
Actual copy of script doing the work?

I gave it in crontab
02 0 * * * > /var/spool/mail/dummy
Note that this also failed from the command line so it is NOT a cron
problem.

Personally, as an old maintenance programmer I prefer code which is
readable at a glance by anyone. As example I would have used
truncate -s 0 /var/spool/mail/dummy
rather than having to check the previous line to see if there was/needs
a trailing \.

No previous line

The file is in a directory mounted from an encrypted filesystem.

Going to make a wild ass guess, problem will be result of the above
and a gotcha as a result of changing nfs mount changes in recent past. :)

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On Wed, 11 Mar 2020 16:06:06 -0000 (UTC), William Unruh wrote:

I finally got tired of investigating and did
rm /var/spool/mail/dummy
as root, and then
touch /var/spool/mail/dummy
and now

/var/spool/mail/dummy

worked without error

So it becomes "What the hell happened?" and not
"How can I fix this"

based on the above, all I can guess is you had an acl on the file
or file header was corrupt. Without knowing what was triggering the insufficient privilege error there is no way to surmise what happened.


--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On 2020-03-11, Bit Twister <BitTwister@mouse-potato.com> wrote:

On Wed, 11 Mar 2020 16:06:06 -0000 (UTC), William Unruh wrote:

I finally got tired of investigating and did
rm /var/spool/mail/dummy
as root, and then
touch /var/spool/mail/dummy
and now

/var/spool/mail/dummy

worked without error

So it becomes "What the hell happened?" and not
"How can I fix this"

based on the above, all I can guess is you had an acl on the file
or file header was corrupt. Without knowing what was triggering the insufficient privilege error there is no way to surmise what happened.

As mentioned,
lsattr /var/spool/mail/dummy
gave nothing except a long line of dashes.
-------------------- /var/spool/mail/dummy

What I want is to know why it was giving me the permission denied as
root to doing emptying the file with > command.


--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On Thu, 12 Mar 2020 02:31:00 -0400, William Unruh <unruh@invalid.ca> wrote:

As mentioned,
lsattr /var/spool/mail/dummy
gave nothing except a long line of dashes.
-------------------- /var/spool/mail/dummy

What I want is to know why it was giving me the permission denied as
root to doing emptying the file with > command.

Now that the file has been deleted, and no one else seems to have the problem, there is no way that I know of to figure out what the problem was. If it
shows up again, then it can be debugged.

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On 13/3/20 3:26 am, David W. Hodgins wrote:

On Thu, 12 Mar 2020 02:31:00 -0400, William Unruh <unruh@invalid.ca> wrote:

As mentioned,
lsattr /var/spool/mail/dummy
gave nothing except a long line of dashes.
-------------------- /var/spool/mail/dummy

What I want is to know why it was giving me the permission denied as
root to doing emptying the file with > command.

Now that the file has been deleted, and no one else seems to have the problem,
there is no way that I know of to figure out what the problem was. If it shows up again, then it can be debugged.

Regards, Dave Hodgins

What I would have done, and it may not have helped, is to change the permissions back to the original. I have had similar but not identical experiences. For example, if the file in question was in a directory
with no "x" permission, it would have been inaccessible from outside.

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: Aioe.org NNTP Server (2:250/0@fidonet)

On 2020-03-14, Doug Laidlaw <laidlaws@hotkey.net.au> wrote:

On 13/3/20 3:26 am, David W. Hodgins wrote:

On Thu, 12 Mar 2020 02:31:00 -0400, William Unruh <unruh@invalid.ca> wrote: >>

As mentioned,
lsattr /var/spool/mail/dummy
gave nothing except a long line of dashes.
-------------------- /var/spool/mail/dummy

What I want is to know why it was giving me the permission denied as
root to doing emptying the file with > command.

Now that the file has been deleted, and no one else seems to have the
problem,
there is no way that I know of to figure out what the problem was. If it
shows up again, then it can be debugged.

Regards, Dave Hodgins

What I would have done, and it may not have helped, is to change the permissions back to the original. I have had similar but not identical experiences. For example, if the file in question was in a directory
with no "x" permission, it would have been inaccessible from outside.

The directory certainly had "x" permission for root
drwxrwsrwt 3 root mail 4096 Mar 13 21:30 /var/spool/mail

Now maybe the "t" messed it up, but it works now with the same directory permission.

Oops, it workd a couple of days ago, and now is once again refusing to
work.
(Note that root is in the mail group)

info:18.0[root]>l -d /var/spool/mail
drwxrwsrwt 3 root mail 4096 Mar 13 21:35 /var/spool/mail
info:18.0[root]>l /var/spool/mail/dummy
-rw-rw---- 1 dummy mail 376947 Mar 13 21:30 /var/spool/mail/dummy info:18.0[root]>> /var/spool/mail/dummy
-bash: /var/spool/mail/dummy: Permission denied


info:18.0[root]>chmod -t /var/spool/mail
info:18.0[root]>l -d /var/spool/mail
drwxrwsrwx 3 root mail 4096 Mar 13 21:35 /var/spool/mail
info:18.0[root]>> /var/spool/mail/dummy
info:18.0[root]>
(Note I have aliased l to "ls -la")

So it does seem to be the "t" permission on the directory. But that
does not change my being able to do
vi /var/spool/mail/dummy
empty it

From man chmod

RESTRICTED DELETION FLAG OR STICKY BIT
The restricted deletion flag or sticky bit is a single bit, whose interpretation depends on the file type. For directories, it
prevents unprivileged users from removing or renaming a file in the directory unless they own the file or the directory; this
is called the restricted deletion flag for the directory, and is commonly found on world-writable directories like /tmp.

But I am neither removing or renaming the file, and root owns the
directory. So this should not be problematic.

A Bug?


--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On Sat, 14 Mar 2020 04:46:40 -0000 (UTC), William Unruh wrote:

The directory certainly had "x" permission for root
drwxrwsrwt 3 root mail 4096 Mar 13 21:30 /var/spool/mail

Now maybe the "t" messed it up, but it works now with the same directory permission.

Oops, it workd a couple of days ago, and now is once again refusing to
work.
(Note that root is in the mail group)

info:18.0[root]>l -d /var/spool/mail
drwxrwsrwt 3 root mail 4096 Mar 13 21:35 /var/spool/mail

Why make it so complicated?
Worse. why is the world/other able to write into the mail directory?

$ ls -ald /var/spool/mail
drwxrwsr-x 2 root mail 4096 Mar 14 00:05 /var/spool/mail

# > /var/spool/mail/dummy
# > /var/spool/mail/dummy

$ ls -Al /var/spool/mail | head -3
total 4
-rw------- 1 bittwister mail 607 Mar 13 23:46 bittwister
-rw-r--r-- 1 root mail 0 Mar 14 00:11 dummy

# \rm /var/spool/mail/dummy
#

And why are you having to put root in the mail group?

I have no users in the mail group, just my MTA.
$ grep mail: /etc/group
mail:x:12:postfix

I have user cron jobs running fetchmail pulling down mail from yahoo,
gmail,... dropping them in /var/spool/mail/user_here files.

I have dovecot daemon/service up and running so user accounts can read
email with thunderbird. Working just fine for
$ grep --count thunderbird /etc/passwd
6
and all user /var/spool/mail files are -rw------- with UID mail as owner/group.





--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On Sat, 14 Mar 2020 00:46:40 -0400, William Unruh <unruh@invalid.ca> wrote:

The directory certainly had "x" permission for root
drwxrwsrwt 3 root mail 4096 Mar 13 21:30 /var/spool/mail

Now maybe the "t" messed it up, but it works now with the same directory permission.

It is definitely causing the problem.

Oops, it workd a couple of days ago, and now is once again refusing to
work.
(Note that root is in the mail group)

More accurately, it works when it first creates the file. It fails every time after that, whether that failure is noticed or not.

info:18.0[root]>l -d /var/spool/mail
drwxrwsrwt 3 root mail 4096 Mar 13 21:35 /var/spool/mail
info:18.0[root]>l /var/spool/mail/dummy
-rw-rw---- 1 dummy mail 376947 Mar 13 21:30 /var/spool/mail/dummy info:18.0[root]>> /var/spool/mail/dummy
-bash: /var/spool/mail/dummy: Permission denied

The "set user or group ID on execution (s)" permission combined with the "restricted deletion flag for the directory (t)" means only the files owner
can write to the file after it's been created.

[root@x3 ~]# mkdir /var/mytestdir
[root@x3 ~]# chmod g+sw /var/mytestdir
[root@x3 ~]# chmod o+twx /var/mytestdir
[root@x3 ~]# ls -ld /var/mytestdir
drwxrwsrwt 2 root root 4096 Mar 14 07:50 /var/mytestdir/
[root@x3 ~]# su -l dave -c 'touch /var/mytestdir/dummy'
[root@x3 ~]# ls -l /var/mytestdir/
total 0
-rw-rw-r-- 1 dave root 0 Mar 14 07:54 dummy
[root@x3 ~]# echo ' ' >> /var/mytestdir/dummy
-bash: /var/mytestdir/dummy: Permission denied

[dave@x3 ~]$ echo morestuff >> /var/mytestdir/dummy
[dave@x3 ~]$ cat /var/mytestdir/dummy
morestuff

What mail transfer agent are you using? I'm using postfix and have the following permissions ...
[root@x3 ~]# ls -ld /var
drwxr-xr-x 24 root root 4096 Mar 14 07:50 /var/
[root@x3 ~]# ls -ld /var/spool
drwxr-xr-x 13 root root 4096 Mar 11 13:09 /var/spool/
[root@x3 ~]# ls -ld /var/spool/mail
drwxrwxr-x 2 root mail 4096 Mar 14 06:58 /var/spool/mail/
[root@x3 ~]# ls -ld /var/spool/mail/dave
-rw-rw---- 1 dave mail 562 Mar 14 06:58 /var/spool/mail/dave

The root user does not receive mail, and for security it should not.

# tail /etc/postfix/aliases|head -n 3
# CHANGE THIS LINE to an account of a HUMAN
root: dave
apache: dave

Don't forget to run the newaliases command and restart postfix after changing the aliases file.

What prompted you to make these permission changes in the first place?

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On 2020-03-14, Bit Twister <BitTwister@mouse-potato.com> wrote:

On Sat, 14 Mar 2020 04:46:40 -0000 (UTC), William Unruh wrote:

The directory certainly had "x" permission for root
drwxrwsrwt 3 root mail 4096 Mar 13 21:30 /var/spool/mail

Now maybe the "t" messed it up, but it works now with the same directory
permission.

Oops, it workd a couple of days ago, and now is once again refusing to
work.
(Note that root is in the mail group)

info:18.0[root]>l -d /var/spool/mail
drwxrwsrwt 3 root mail 4096 Mar 13 21:35 /var/spool/mail

Why make it so complicated?
Worse. why is the world/other able to write into the mail directory?

For the same reason as the world is able to write in the /tmp directory.
The "t" ensures that ONLY the owner of a file is able to delete the
file, or change the file. The mail files are owned by the owners of the
mail.
root would be able to do anything anyway, so not allowing writing would
be pointless.
group mail is able to write (which is the group for postfix) because
it has to write files to the directory.
The owners of their own incoming mail files need to be able to write
because they have to be able to change their own mail.
I still use pine, and pine does NOT copy the INBOX
(/var/spool/mail/<username> to another file before using it. And pine is
NOT suid root, which would be a far far worse security hole.

$ ls -ald /var/spool/mail
drwxrwsr-x 2 root mail 4096 Mar 14 00:05 /var/spool/mail

# > /var/spool/mail/dummy
# > /var/spool/mail/dummy

$ ls -Al /var/spool/mail | head -3
total 4
-rw------- 1 bittwister mail 607 Mar 13 23:46 bittwister
-rw-r--r-- 1 root mail 0 Mar 14 00:11 dummy

# \rm /var/spool/mail/dummy
#

And why are you having to put root in the mail group?

I do not. I tried that to see if wouldmake a difference to the behaviour
of >dummy. It did not. So root never was a member and is not now.

I have no users in the mail group, just my MTA.
$ grep mail: /etc/group
mail:x:12:postfix

Same here.

I have user cron jobs running fetchmail pulling down mail from yahoo, gmail,... dropping them in /var/spool/mail/user_here files.

mail gets delivered directly to this machine so postfix filters them for
spam, and then deposits it in /var/spool/main/user_here

I have dovecot daemon/service up and running so user accounts can read
email with thunderbird. Working just fine for
$ grep --count thunderbird /etc/passwd
6
and all user /var/spool/mail files are -rw------- with UID mail as

owner/group.

Fine, you organize your files as you want, and I organize them as I
want. One is not worse than the other ( except for the problem of suid
root files.)

So, after that discursion, why is root unable to empty a user's file
with
>dummy
if the directory had the "t" permission (sticky bit set) but root is able to remove it, edit it, change it,... as root should be able to . Any why
has this behaviour changed in Mga7. (This worked without problem with Mga5-- I have used it for
at least 10 years).












--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On 2020-03-14, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:

On Sat, 14 Mar 2020 00:46:40 -0400, William Unruh <unruh@invalid.ca> wrote:

The directory certainly had "x" permission for root
drwxrwsrwt 3 root mail 4096 Mar 13 21:30 /var/spool/mail

Now maybe the "t" messed it up, but it works now with the same directory
permission.

It is definitely causing the problem.

Yes, but why? root should be able to change anything.
And the file has
permissions rw-rw----- dummy mail

In my crotab, I am now doing
cd /var/spool/mail&& /bin/rm -f dummy; touch dummy; chown dummy.mail; chmod ug+rw dummy

Certainly a far more complicated line.

Note that everything works as before on an Mda7 system with kernel
5.1.4. The same setup but >dummy works. This system on which I am having trouble has kernel 5.5.4.
Is that the difference? I have no idea-- there could be other differences
as well, but something seems to have changed.

Oops, it workd a couple of days ago, and now is once again refusing to
work.
(Note that root is in the mail group)

More accurately, it works when it first creates the file. It fails every

time

after that, whether that failure is noticed or not.

info:18.0[root]>l -d /var/spool/mail
drwxrwsrwt 3 root mail 4096 Mar 13 21:35 /var/spool/mail
info:18.0[root]>l /var/spool/mail/dummy
-rw-rw---- 1 dummy mail 376947 Mar 13 21:30 /var/spool/mail/dummy
info:18.0[root]>> /var/spool/mail/dummy
-bash: /var/spool/mail/dummy: Permission denied

The "set user or group ID on execution (s)" permission combined with the "restricted deletion flag for the directory (t)" means only the files owner can write to the file after it's been created.

[root@x3 ~]# mkdir /var/mytestdir
[root@x3 ~]# chmod g+sw /var/mytestdir
[root@x3 ~]# chmod o+twx /var/mytestdir
[root@x3 ~]# ls -ld /var/mytestdir
drwxrwsrwt 2 root root 4096 Mar 14 07:50 /var/mytestdir/
[root@x3 ~]# su -l dave -c 'touch /var/mytestdir/dummy'
[root@x3 ~]# ls -l /var/mytestdir/
total 0
-rw-rw-r-- 1 dave root 0 Mar 14 07:54 dummy
[root@x3 ~]# echo ' ' >> /var/mytestdir/dummy
-bash: /var/mytestdir/dummy: Permission denied

[dave@x3 ~]$ echo morestuff >> /var/mytestdir/dummy
[dave@x3 ~]$ cat /var/mytestdir/dummy
morestuff

What mail transfer agent are you using? I'm using postfix and have the following permissions ...
[root@x3 ~]# ls -ld /var
drwxr-xr-x 24 root root 4096 Mar 14 07:50 /var/
[root@x3 ~]# ls -ld /var/spool
drwxr-xr-x 13 root root 4096 Mar 11 13:09 /var/spool/
[root@x3 ~]# ls -ld /var/spool/mail
drwxrwxr-x 2 root mail 4096 Mar 14 06:58 /var/spool/mail/
[root@x3 ~]# ls -ld /var/spool/mail/dave
-rw-rw---- 1 dave mail 562 Mar 14 06:58 /var/spool/mail/dave

The root user does not receive mail, and for security it should not.

# tail /etc/postfix/aliases|head -n 3
# CHANGE THIS LINE to an account of a HUMAN
root: dave
apache: dave

Don't forget to run the newaliases command and restart postfix after

changing

the aliases file.

What prompted you to make these permission changes in the first place?

Regards, Dave Hodgins

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On Sat, 14 Mar 2020 11:48:16 -0400, William Unruh <unruh@invalid.ca> wrote:

For the same reason as the world is able to write in the /tmp directory.
The "t" ensures that ONLY the owner of a file is able to delete the
file, or change the file. The mail files are owned by the owners of the
mail.

It is not needed, and as you've seen can cause problems.

/var/spool/mail is owned by root, with the group mail. Postfix runs as
the mail user, so it's able to create and update files in /var/spool.
The files in /var/spool are owned by the user receiving the mail, with
the group set to mail, so that postfix can update the file, as can the
user.

Only root, the programs running as mail, and the user can update those
files.

Additional settings such as the restricted deletion flag not only do not
make things safer, they break the way it's supposed to work.

The directories /var/spool, and /var/spool/mail are not supposed to be
world writable like /tmp is.

I have user cron jobs running fetchmail pulling down mail from yahoo,
gmail,... dropping them in /var/spool/mail/user_here files.

It would be safest to have those cron jobs run fetchmail as a user such as postfix, that can update those files, but not other files, rather then as root.

mail gets delivered directly to this machine so postfix filters them for spam, and then deposits it in /var/spool/main/user_here

So, after that discursion, why is root unable to empty a user's file
with
>dummy
if the directory had the "t" permission (sticky bit set) but root is able to remove it, edit it, change it,... as root should be able to . Any why
has this behaviour changed in Mga7. (This worked without problem with Mga5--

I have used it for

at least 10 years).

Either the permissions that were set were different, or you never tried to update the file while running as root. It's always worked that way since I started using linux.

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On 2020-03-14, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:

On Sat, 14 Mar 2020 11:48:16 -0400, William Unruh <unruh@invalid.ca> wrote:

For the same reason as the world is able to write in the /tmp directory.
The "t" ensures that ONLY the owner of a file is able to delete the
file, or change the file. The mail files are owned by the owners of the
mail.

It is not needed, and as you've seen can cause problems.

No, what I have is NOT a problem with the permissions, but with
something that happened recently in Mageia or in the kernel.

/var/spool/mail is owned by root, with the group mail. Postfix runs as
the mail user, so it's able to create and update files in /var/spool.
The files in /var/spool are owned by the user receiving the mail, with
the group set to mail, so that postfix can update the file, as can the
user.

Only root, the programs running as mail, and the user can update those
files.

The issue is that root cannot update those files. This has been
something which has occured just recently ( past few weeks) perhaps
after I installed Kernel 5.5

Additional settings such as the restricted deletion flag not only do not
make things safer, they break the way it's supposed to work.

No idea how they break the way it is supposed to work. That sticky bit
says only the user and mail are allowed to change the files.

The directories /var/spool, and /var/spool/mail are not supposed to be
world writable like /tmp is.

Simply repeating things is not an argument.

If one is running alpine, then one needs it to be world writable.
I believe it is an issue about setting locks

See http://www.washington.edu/imap/IMAP-FAQs/#7.10
which gives a long justification of the use of 1777 and why it is NOT a security hole.

I have user cron jobs running fetchmail pulling down mail from yahoo,
gmail,... dropping them in /var/spool/mail/user_here files.

It would be safest to have those cron jobs run fetchmail as a user such as postfix, that can update those files, but not other files, rather then as

root.

mail gets delivered directly to this machine so postfix filters them for
spam, and then deposits it in /var/spool/main/user_here

So, after that discursion, why is root unable to empty a user's file
with
>dummy
if the directory had the "t" permission (sticky bit set) but root is able to
remove it, edit it, change it,... as root should be able to . Any why
has this behaviour changed in Mga7. (This worked without problem with Mga5-- I have used it for
at least 10 years).

Either the permissions that were set were different, or you never tried to update the file while running as root. It's always worked that way since I started using linux.

Nope, the permission were set that way for the past N years, where N is
a very large number. I had a discussion with Mageia and with Eduardo
Chappa in 2016 re the permission who sent me to the above link.
And the emptying of dummy has been working for many many years, untill a
couple of weeks ago.

Regards, Dave Hodgins

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)