Re: Thomas Roessler 2007-03-17
<20070317174032.GE30802@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
> 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.
>
> 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.
Security is much about defaults ("no surprises"). The current umask
patch has umask=077 which makes all folders 0600, so that's fine.
> - 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.
The point of umask is to provide a convenient way to set stricter
permissions. The open() calls for tempfiles in Mutt are already
something like open(filename, 0600), so a (possibly) less strict umask
does not affect them. (See also below.)
> 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.
I agree that folders should be 0600 most of the time. What is quite
annoying though is that saved attachments are also 0600 which bugs me
every time I scp one to the tmp folder on my web server and then get
404. (I won't argue for yet another variable here, though. Bonus
complexity for "folders" vs. "attachments saved as files" vs.
"messages saved in files which are not to be used as folders".)
> 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
> --, and the risks that come with screwing up the more complex case,
> then it's pretty clear to me that the single umask(077) is the way
> to go.
The bug with umask(077) in main.c is that subshells (by the ! command)
have the wrong umask. The way I tried to address it in my patch was to
change umasks only at defined points (when $umask changes/is set the
first time) and delegate the security aspects to the 077 default and
the user who should be informed of the implications when changing it.
(The documentation could probably use a warning here.)
As said I was looking for comments. At the moment I would be fine as
well if just item #1 of my list (umask(077) in main.c) was fixed.
#2 (no way to say "use my umask" in .muttrc) is not this important.
(Fixing it without ORing with the parent process' umask would require
a new variable which is imho just overly complex.)
#3 (umask limbo) is what Thomas adresses here. While I agree that
complexity in a security context is bad, IMHO bugs here are just bugs
that should be fixed. (An alternative approach would be to re-set the
umask only for subshells etc.)
Christoph
--
cb@xxxxxxxx | http://www.df7cb.de/
Attachment:
signature.asc
Description: Digital signature