On Tuesday, 20 March 2007 at 10:35, Thomas Roessler wrote: > On 2007-03-19 14:54:04 -0700, Brendan Cully wrote: > >>- 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. > Because you don't know who has access to these folders. In any > event, it's the usual behavior, and that was the point of this > paragraph. The user creating the mailbox does. The MUA has a slightly different view than an MDA here, I think. But sure, I have no problem with new mailboxes being created 077. > >> 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? > I mean "never." My point is precisely that umask (077) and not > bothering any more in the MUA takes care of almost all use cases, > and is therefore all we need to do. There's another annoying problem with mutt's old umask handling: even if we agree that new mailboxes ought to be created 077, mutt makes it very hard to work with shared mailboxes. If you copy a message into an existing maildir which is meant to be group read/writable, you break it. At the very least, I think mutt ought to respect the permissions already applied to an existing mailbox. I also very much like being able to save attachments as other than 077, and I think I agree that pipe commands should use the shell's umask, not mutt's - though this last one is not critical IMHO. > >$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. > Yes. > But you have to weigh the downsides of the change against this: > - Code messiness. (And yes, this is a significant consideration in > this.) I agree. > - Introducing a configuration variable for an operation that doesn't > call for changing the default, but (possibly) for a case-by-case > change. Ok. It is possible that we don't need $umask, if we can keep the shell's mask for certain specific operations (attachment saving at least), and preserve the permissions on existing mailboxes. Converting group read/writable mailboxes to 077 on change really does seem broken to me. > I think that the code messiness alone (together with the old code > taking care of most relevant use cases) would warrant not taking > this patch in. I'm open to backing out $umask, if a better approach can be found.
Attachment:
pgp7SK9lXjZq5.pgp
Description: PGP signature