Why is /var/mail setgid?

Question

I am learning about UNIX file permissions and I saw that on my Ubuntu system, /var/mail has the setgid bit set. Why is this?

$ ls /var/mail/ -dl
drwxrwsr-x 2 root mail 4096 Feb  23 05:57 /var/mail/

This book I'm reading says:

Setgid is useful when you have groups of users who need to share a lot of files. Having them work from a common directory with the setgid attribute means that correct group ownership will be automatically set for new files, even if the people in the group don’t share the same primary group.

That description doesn't sound like anything useful for /var/mail since users don't directly manipulate that directory.

The files created in /var/mail end up with the group owner "mail", but doesn't this already happen? Only "mail" can create new files in the directory (and root).

The only useful case I can think of is when a sysadmin adds a new mail account with sudo touch /var/mail/<user>. That file would still have the "mail" group owner.

Answer 1

The local email is not handled by just one service, but several services. Besides the actual Mail Transfer Agent (MTA for short: typically postfix, exim, sendmail or similar), there can be mail filtering/post-processing utilities (like the old procmail), services to enable remote access to user mailboxes (various POP and IMAP services), mailing list management utilities, and many others.

Historically, such services used to be run as root, because they needed to be able to access every user's mailbox, and the mailboxes had to be accessible only by their owners. But it soon turned out that having the email system running as root was a big chunk of code that was ripe for exploits. Many, many vulnerabilities were found and fixed, but eventually it was recognized that running the mail system as root was a bad idea. The solution for that was to create the group mail, and make all the components of the email services that need to deliver mail to users' mailboxes setgid to that group.

But by that time, the amount of mail-related tools was already so large that it was impossible to guarantee a perfect change-over. So, as an insurance, the parent directory of user inboxes, /var/mail/ was also made setgid mail, to ensure that all software that delivers mail to users' inboxes will automatically create any new inboxes with the correct group. The remaining task was to patch or configure all mail delivery programs to use the correct umask for users' inboxes: when the mail system was running as root, they could have used umask 077 (for permissions -rw-------), but with the group mail in effect, umask 007 (for permissions -rw-rw----) was needed. But this was an adjustment of a pre-existing requirement, rather than adding a new responsibility to enforce the correct group, so it was a simpler change.

(Of course, adding the enforcement of the correct group was definitely a good idea - but making /var/mail setgid mail made that code change optional and less urgent.)

And yes, most programs that deliver mail to users' inboxes in /var/mail/ will automatically create a mailbox file for a user if the file does not exist - so having an user with no mailbox file until the user receives their first incoming email is perfectly valid.

To summarize: having /var/mail/ setgid mail is one-part insurance policy against misconfigured mail delivery programs, and one-part a historical remnant from the transition away from the dark ages when the email services ran fully as root all the time.

Answer 2

Within /var/mail/ the individual files are uid the delivery user. This allows any user to be able to write or read files of their own uid in a directory where they otherwise have no permission. If it were not setgid, users could not delete their own mail.

And users do read and delete their own mail files - vide mutt.