Willy -- ...and then Willy Sutrisno said... % % * David T-G ([EMAIL PROTECTED]) wrote: % > Aha! While mutt_dotlock is group mail, it does not have the sgid bit % > set, so it gets run as the calling user. You need root to % > % > chmod g+s /usr/local/bin/mutt_dotlock % The above command really solved my problem. Thx man for the help!
Sure thing!
%
% I can't believe it, its the mutt_dotlock that cause the problem. Can you explain
Well, "cause" might be putting it a bit strongly... I'd say it was
permissions on a file that cause the problem and that root is to blame.
% to me, why does that program affect my mailbox. I never run that prog before,
Not a problem.
In order for mutt (or any program, be it a user agent like mutt or pine
or a delivery or transport agent like procmail or sendmail)) to write to
your mail spool file without risk of corruption when something else wants
to write there, all of these programs have to have a locking mechanism
that says "I am modifying this file; don't touch it". There are three
kinds of locking, and the one you're using is called "dotlocking";
for a file foo, a lock file called foo.lock ("foo dot lock", and hence
"dotlock") gets created in the same directory.
If a process wants to write to the mailbox, such as to deliver new mail
or to write replied/deleted/whatever flags, it first checks to see that
there is no lockfile and then tries to create one; if it can successfully
create the lock file, then it knows that it can write without worry.
When it's done, it deletes the lock file so that something else can
write to the file as necessary.
Note that I said "in the same directory" up above. When you're working
with mailboxes in your home directory, of course you have permissions to
do anything you wish. When you're in /var/mail, however, you as a user
do not have permission to create any files there because it looks like
drwxrwsr-x 2 root mail 4096 May 2 00:00 /var/mail/
and we see that you must be either root or in the mail group to write
there because world write permissions are turned off (just as they
should be). The way to ensure this is to give the program that has
to do the locking special permissions, called "set-UID" or "set-GID",
which respectively set the effective user ID or group ID when the process
is run.
Now, some admins don't want to give a big, complex program like mutt
(even though it's tight and fast, it's still a lot of lines of C code!)
special permissions; after all, there might be a trojan horse or even a
simple bug in there that could wreak havoc on your system. Because of
that, there is a very short and simple program called mutt_dotlock whose
only function is to create and remove dotlock files, and *it* is what
gets the special permissions. It does very little and it takes only
certain arguments, so it's easy to see that it's not a trojan horse and
also easy to debug.
% neither I do something with the permission.
Let's back up for a moment... Has your mail always been in /var/mail,
or have you been working with a mailbox under your home directory?
Have you used mutt for a long time, or switched to it only recently from,
say, PINE? You really didn't build and install or reinstall? I noticed
that mutt and mutt_dotlock were timestamped April 21, which is only last
week; *something* had to have changed on Sunday.
%
% Anyway, thanks very much.
HTH & HAND
%
% --
% Willy
% [ http://web.singnet.com.sg/~sutrisno ]
% Linux User #225035 - http://counter.li.org
:-D
--
David T-G * It's easier to fight for one's principles
(play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie
(work) [EMAIL PROTECTED]
http://www.justpickone.org/davidtg/ Shpx gur Pbzzhavpngvbaf Qrprapl Npg!
msg27785/pgp00000.pgp
Description: PGP signature
