Hello,
I've been hit by the same bug while trying to delete some messages in my
local mbox with the regular "mail" command. I'm also running mailutils
3.11.1-4 on a sid machine.
While investigating I found out that version 3.11 of mailutils
introduced a rewrite of their traditional mbox handling code. According
to the source code of that "mboxrd" component (libproto/mbox/mboxrd.c),
it appears that when flushing mbox changes to disk, the program will
create and write to a temporary mailbox. If it succeeds, it will then
rename it to your current mbox name. This behavior seems incompatible
with the permissions of /var/mail on a Debian system (2775 root:mail).
When running strace on "mail", I've found this just after issuing the
'quit' command, which seems to confirm the problem :
openat(AT_FDCWD, "/var/mail/username", O_RDWR) = 6
fcntl(6, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0,
l_len=0}) = 0
rt_sigprocmask(SIG_BLOCK, [HUP INT TERM TSTP WINCH], NULL, 8) = 0
msync(0x7f469e481000, 16357, MS_SYNC) = 0
fstat(4, {st_mode=S_IFREG|0660, st_size=16357, ...}) = 0
stat("/var/mail", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
openat(AT_FDCWD, "/var/mail/muMAULJT", O_RDWR|O_CREAT|O_EXCL, 0600) = -1
EACCES (Permission non accordée)
NOTE : "Permission non accordée" translates to "Permission denied"
It's also worth noting that running 'mail -u username' as root works and
I can delete my messages, but it modifies /var/mail/username permissions
(0600 root:mail instead of 0660 username:mail), as expected with that
temporary mbox + renaming way of doing.
Best regards,
--
Pierrick CHANTEUX
Service Informatique
Institut de Physique du Globe de Paris
1, rue Jussieu - 75005 Paris
