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?
The file is in a directory mounted from an encrypted filesystem.
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.
/var/spool/mail/dummyas root from a terminal, and from that cron running as root.
/var/spool/mail/dummyworked without error
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. :)
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/dummyworked without error
So it becomes "What the hell happened?" and not
"How can I fix this"
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/dummyworked 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.
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
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: >>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
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
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
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
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 readowner/group.
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
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.
timeOops, 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
after that, whether that failure is noticed or not.changing
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
the aliases file.
What prompted you to make these permission changes in the first place?
Regards, Dave Hodgins
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.
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_hereI have used it for
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--
at least 10 years).
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.
root.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
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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 62:44:35 |
| Calls: | 6,654 |
| Files: | 12,200 |
| Messages: | 5,331,627 |