Description of problem: The permissions on /var/spool/mail should be 1777, not 2775 if alpine is installed. alpine allows multiple versions to be opened, but if in one of them an attachement is being viewed, or if a reply is being made in the first version, then the second opening of alpine goes into an infinite spin trying to open INBOX. This appears to be because the user cannot properly open or manipulate a lock file in /var/spool/mail if it does not have write permission on the directory. The 1777 allows that without allowing other uses to erase others mail files. This also needs to be changed in msec /etc/security/msec/perm.* Version-Release number of selected component (if applicable): How reproducible: Very Steps to Reproduce: 1. Install alpine. 2.open one version of alpine and reply to one of the messages. I use the vi editor, and leave the editory open. 3.open another version of alpine and try to open the INBOX. Wait forever (or until you close the first editor) Similarly, open an email with a .doc or .odt attachment. Open the attachment with libreoffice. Then try to open a new alpine and go into INBOX. Wait forever.
NO WAY! That's opening up the system to a Wole buch of security related issues... anything that needs World writable system dirs is broken by design and should be fixed properly, not hacked around like this... file a bug upstream about broken behaviour...
CC: (none) => tmb
.
Status: NEW => RESOLVEDResolution: (none) => INVALID
But /tmp has permission 1777 for precisely the same reason, users need to be able to write to /tmp but the "t" permission stops them from erasing other's files. I am not sure what "security related issues" are of concern in /var/spool/mail with those permissions. Alpine runs as user, not system and making alpine run as system . Sorry to bother you but I would need this ammunition to convince upstream to change the behaviour. I am rechanging to REOPENED so I can get some ammunition to persuading upstream to do something about this. Thanks
Status: RESOLVED => REOPENEDResolution: INVALID => (none)
(In reply to w unruh from comment #3) > But /tmp has permission 1777 for precisely the same reason, users need to be > able to write to /tmp but the "t" permission stops them from erasing other's > files. > > I am not sure what "security related issues" are of concern in > /var/spool/mail > with those permissions. Alpine runs as user, not system and making alpine > run as system . > > Sorry to bother you but I would need this ammunition to convince upstream to > change the behaviour. > I am rechanging to REOPENED so I can get some ammunition to persuading > upstream to do something about this. > Thanks Assigning to maintainer, this is beyond my knowledge
Assignee: bugsquad => cjwCC: (none) => marja11
I doubt alpine really supports running two instances, is this documented somewhere? When I tried it on cauldron, I didn't get any problems from alpine, but mail that was already filtered by the first instance got filtered again causing some mailing list folders to have duplicates of recent messages. I'm sill not following the only active fork of alpine so currently there is no upstream to complain to, just me /o\. OK my test was not really what you described so I tried again while in reply mode (using the builtin (al)pico editor). Now it displayed "trying to get lock from process xxxx" for a few seconds, but then it continued. Again a mail got filtered twice causing a duplicate in the ml folder. $ ls -ld /var/spool/mail drwxrwxr-x 2 root mail 4096 Apr 29 00:10 /var/spool/mail
CC: (none) => cjw
Eduardo Chappa is actively maintaining alpine ( it is now 2.20) http://patches.freeiz.com/alpine/ I use /var/spool/mail Unix style mail not ml style. For me using various ones has worked for the last 15 years at least. But it seems that what is happening is that a lock file is being written into /var/spool/mail by alpine as user, and since user does not have permissions to write to /var/spool/mail that is causing trouble. It also writes into /tmp/ the current pid into a file that starts with .fc (at least on my system) It is often very useful to open a second copy. You are answering a mail, and the answer requires data from a different email.
By the way, are you a member of the mail group? I think that would also work, since /var/spool/mail is group mail. However putting everyone that wants to use mail into the mail group seems to me to be far more of a security concern than making /var/spool/mail 1777. I do not have mail folder filters set up, so the filtering is not a problem for me.
(In reply to w unruh from comment #7) > By the way, are you a member of the mail group? No, my user is not a member of the mail group. (In reply to w unruh from comment #6) > I use /var/spool/mail Unix style mail not ml style. you mean maildir, ml=mailing list (: Some of my mailing list folders are maildirs but that is not relevant for this issue, my /var/spool/mail/* is mbox format. > It is often very useful to open a second copy. You are answering a mail, and > the answer requires data from a different email. Maybe the problem is with the alternate editor feature you are using, the built-in pico is just a function in alpine while your vi is forked. But even in alt mode, pine checks for new mail. I haven't found any obvious difference so far, maybe I need to look for the locking code. What is your explanation for the problem only occurring when viewing an attachment or editing a mail in an alternate editor? If the problem is with the locking itself then it would also happen when the "first" pine is displaying some folder (other than inbox) or folder list.
Yes, it confused me as well-- what was different if I was editing a response? I have seen two locks. One is a file in /tmp which starts with .f Eg, .fc00.10 right now which seems to contain the pid of the latest opened alpine. The other I have occasionally seen a "unruh.lock" file in /var/spool/mail. I am not sure where it comes from. It is really hard to figure out exactly what is going on. I am not sure where alpine maintains its lock files-- it must since a second version talks about getting the lock from the first. I had a quick look at strace of alpine, and alpine locks and unlocks the file in /tmp and also it creates and destroys file locks and files in /var/spool/mail like unruh.lock and unruh.lock.7576q936.wormhole If alpine does not have write permission for the alpine user in /var/spool/mail, then it cannot create such files, and I could imagine how that could cause trouble. There is a long screed on alpine requiring 1777 permissions on /var/spool/mail in the alpine source code in pith/pine.hlp for locking purposes. They argue that this is not dangerous, and in any case is far less dangerous than having alpine run with special priviledges (guid) It also requires 1777 on the /tmp directory. The lock on /var/spool/mail is so o that they can coordinate/lock with the mail delivery agent (eg procmail)) There are also numerous comments in imap/FAQ.html in the alpine source which again says that the /var/spool/mail needs to be 1777. So, yes, alpine needs 1777 permission on /var/spool/mail. And I am still confused as to why Thomas Backlund argues that this opens security holes.
From what I could find in alpine documentation, alpine will use flock() (on the spool file itself, you should see that in an strace). Then a lock file in the spool dir is not needed anymore. It looks like alpine may not use flock() on NFS while recent linux kernels (from 2.6.12) support this.
It uses flock both on the /tmp file and on the spool file. Here are some fragments from the strace [pid 11698] open("/tmp/.fc00.15a002", O_RDWR|O_CREAT|O_EXCL, 0666) = 4 This is the file in which the current pid of the alpine is written. It seems to be the same name for successive instances of alpine. It is different for different users. [pid 11698] fstatfs(4, {f_type=0x1021994, f_bsize=4096, f_blocks=504824, f_bfree=503248, f_bavail=503248, f_files=504824, f_ffree=504784, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0 [pid 11698] flock(4, LOCK_EX|LOCK_NB) = 0 Here is flock on that file. [pid 11698] lstat("/tmp/.fc00.15a002", {st_mode=S_IFREG|0666, st_size=0, ...}) = [pid 11698] fstat(4, {st_mode=S_IFREG|0666, st_size=0, ...}) = 0 [pid 11698] chmod("/tmp/.fc00.15a002", 0666) = 0 Not sure why it wants world rw on that file! [pid 11698] umask(07) = 0 [pid 11698] chmod("/tmp/.fc00.15a002", 0666) = 0 [pid 11698] write(4, "11698\0", 6) = 6 [pid 11698] ftruncate(4, 5) = 0 [pid 11698] fsync(4) = 0 ---------------------------------------------------------- And here is later wrt the spool file [pid 11698] lstat("/var/spool/mail/unruh.lock", 0x7ffd13d78bd0) = -1 ENOENT (No such file or directory) Looks for that lock file. [pid 11698] umask(0) = 07 [pid 11698] uname({sys="Linux", node="wormhole", ...}) = 0 [pid 11698] open("/var/spool/mail/unruh.lock.1462047301.11698.wormhole", O_WRONLY|O_CREAT|O_EXCL, 0666) = 5 [pid 11698] close(5) = 0 Creates and immediately closes a random lock file [pid 11698] link("/var/spool/mail/unruh.lock.1462047301.11698.wormhole", "/var/spool/mail/unruh.lock") = 0 And links it to unruh.lock [pid 11698] stat("/var/spool/mail/unruh.lock.1462047301.11698.wormhole", {st_mode=S_IFREG|0666, st_size=0, ...}) = 0 [pid 11698] unlink("/var/spool/mail/unruh.lock.1462047301.11698.wormhole") = 0 [pid 11698] umask(07) = 0 [pid 11698] chmod("/var/spool/mail/unruh.lock", 0666) = 0 I really am not sure what those machinations are for, nor why that file should have 666 permission. [pid 11698] open("/var/spool/mail/unruh", O_RDWR) = 5 [pid 11698] fstatfs(5, {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=7835344, f_bfree=7769963, f_bavail=7370285, f_files=1998848, f_ffree=1998835, f_fsid={-637891078, 1598135558}, f_namelen=255, f_frsize=4096}) = 0 [pid 11698] flock(5, LOCK_SH) = 0 And here is flock on the spool file. [pid 11698] fstat(5, {st_mode=S_IFREG|0600, st_size=217183984, ...}) = 0 [pid 11698] lseek(5, 0, SEEK_SET) = 0 Anyway I do not have enough knowledge of the bahaviour of locks on linux to figure out exactly what is going on here. It may be that this is code from the distant past. I know that the imap/FAQ.html does talk about nfs, and also using a little program that is part of the alpine package of mlock (not to be confused with the function of that name) Note that the above is from alpine 2.20, the latest release by Chappa But 2.03 behaves in the same way.
[ The fstatfs() is probably from alpine's linux-specific safe_lock() function, which does not do locking if the result has fs_type NFS_SUPER_MAGIC. That's what I was referring to earlier, but not related to your locking problems. ] The link() + unlink() simply moves the file (like the mv command does), this is probably done because the link() operation is "atomic" -- this procedure makes sure a different process doesn't check the lock while this process is between checking and setting it. Anyway, I still need to find the code where alpine supposedly asks the other instance to release its lock, since that's what fails for you when the first instance is in alt editor mode or attachment viewer mode.
Perhaps someone could improve the description, but the old one was definitely wrong. The way /var/spool/mail is intended to work, it absolutely should not be world-writable, only writable by the local mail system which deposits mails there. 1777 would allow a user to create a different user's mail file if it doesn't already exist. So, there may be a bug in alpine if it isn't working, but the directory permissions are not the problem. Also, our alpine package is unmaintained has been outdated for a very long time. Maybe updating it would fix the issue?
Summary: Permissions on /var/spool/mail should be 1777 for alpine => alpine is broken
As far as alpine is concerned (both written documentation and discussion with Chappa) alpine is intended to work with rw other permission on /var/spool/mail, just like linux is intended to work with rw permission on /tmp. While your scenario is a possible one, it is rather unlikely, just as it is on /tmp. This behaviour has nothing to do with nfs. Anyway, here is a link to the uwashington site explaining the philosophy behind the permissions ( and it is not a "bug" that is going to be fixed.) http://www.washington.edu/imap/IMAP-FAQs/#7.10
So alpine is broken by design and will stay so... We wont change permissions on /var/spool/mail Feel free to do whatever you want on your local system... And comparing to /tmp is moot as that is _by design_ defined as rw for all
Status: REOPENED => RESOLVEDResolution: (none) => WONTFIX
Furthermore I think you're misinterpreting that. As that FAQ correctly states, your mail subsystem (which *delivers* the mails) runs as mail or setgid mail so that it can create files in that directory. Allowing users to create arbitrary files in that directory would be very bad and they are dead wrong in suggesting otherwise. The only thing something like alpine, a mail *client* needs write access to is your individual mail file, once it's been created, which is normally the case anyway (so it can remove individual mail messages from the file if you delete them). Finally, I wouldn't trust a uw-imap FAQ for anything about security, as that was one of the most notoriously insecure pieces of server software that have ever existed, and that is why it is no longer in use (it has been superceded by dovecot).
I disagree that I am misinterpreting that. Alpine does not work properly unless /var/spool/mail is rw other (rwrwrwt). It is clear that there is a disagreement between mageia and Alpine (eg Chappa the new upstream) about the problems with having /var/spool/mail have other write permission. With your rules, alpine cannot even create the mail file for the user, nor can it lock the file when it is altering it (as you say "so it can remove individual mail messages") without having the danger that the mail delivery agent will write all over the user's file while the user is deleting his messages, creating a mess. Having the mail program be suid root. or even sgid mail is a hell of a lot more dangerous than having /var/spool/mail have the same permissions as /tmp, in my opinion. But you are the Mageia creators, and it is clear I have not convinced you.
Fedora: drwxrwxr-x. 2 root mail 4096 Dec 3 2015 /var/spool/mail FreeBSD: drwxrwxr-x 2 root mail 21 Aug 24 2015 /var/mail Debian: drwxrwsr-x 2 root mail 4096 Feb 7 2014 /var/mail RHEL5: drwxrwxr-x 2 root mail 4096 Jun 8 04:02 /var/spool/mail RHEL6: drwxrwxr-x. 2 root mail 4096 Jun 8 03:17 /var/spool/mail This isn't about Mageia, this is about how these facilities normally work. Alpine is a mail client. It is *not* supposed to create the mail file, nor are users. The MDA (mail delivery agent) running on the machine creates it. It can write to the directory. As I already explained, users do not need to be able to create files in that directory, nor should they be able to, as that would allow them to create someone else's mail file and break the whole system.
Then I do not understand how the mail client can lock the mail file while it is altering the mail file. It is dangerous to have one program, the mail delivery agent (eg procmail) , trying to alter the file (delivering the mail) at the same time as another, the mail client (eg alpine) is altering the file (erasing the mail entries in the file). Having two things altering the file at the same time would certainly break the system, and not with any malicious intent.
A file can be locked by calling flock() on the open file descriptor. These are advisory locks so they are not enforced by the operating system, but as long as all mail programs use this facility, the locking should work. As I indicated earlier, alpine does use flock().