On Saturday, 17 March 2007 at 18:40, Thomas Roessler wrote: > I continue to think that the umask patch should't have been taken > into mutt. However, at this point, the decision is really > Brendan's. > > That said, I think there are several questions to consider here: > > - E-Mail systems are typically set up to create inboxes with rather > paranoid security settings (typically 0600); regardless of what > the user's umask is, e-mail privacy is protected by default. This makes sense for /var/spool/mail, where the user has no control over the permissions of the directory. It makes a little less sense for mailboxes in or below $HOME. New mailboxes _in_ $HOME probably need this. I don't really see why mailboxes in subfolders would. > Saving a message to a new folder should, by default, not expose > messages more broadly than they were exposed before. Therefore, > mutt should *never* create new folders with rights more lenient > than 0600. by *never* I think you mean *never by default* for symmetry with the first sentence? > - What's the typical reason for a lenient umask on a multi-user > system? People collaborating on some project through shared > directories, possibly with local cvs involved. On such systems, > though, it does indeed make sense to be more paranoid about e-mail > than about other user files. Another reason to protect e-mail > more tightly than other files the user creates. > > (And yes, I have worked and continue to work on such systems.) $umask defaults to 077. It's up to the user to override it. But if the user wants to, it's more convenient to do it in mutt than to suspend or quit and navigate to the created folder (and its subdirectories if it is maildir) to fix up the permissions afterward, IMHO. > - Finally, temporary files are supposed to be private to the > application that creates them. There is no good reason whatsoever > to create these files with rights that are any more lenient than > 0600. I completely agree with this. > Concluding, I see only a very limited number of cases in mutt in > which it really makes sense to defer to the user's umask (or a > configured one) in terms of file permissions; in almost all other > cases, 077 is the right umask to apply. > > If you weigh the complexities involved -- a single umask(077) in > main.c vs. a decision about what to do each time a file is opened > then it's pretty clear to me that the single umask(077) is the way > to go. It does seem to be a little messy. But it's safe by default, and convenient when needed.
Attachment:
pgpSeZTvYes4S.pgp
Description: PGP signature