On Wed, May 02, 2001 at 04:46:36PM -0400, Rich Lafferty wrote:
> On Wed, May 02, 2001 at 07:08:28PM +0200, Thomas Roessler
>([EMAIL PROTECTED]) wrote:
> > On 2001-05-02 12:41:12 -0400, Rich Lafferty wrote:
> >
> > > Yep -- strangely enough, this came up in a conversation with a
> > > friend yesterday. Mutt sets umask 077 in main.c and doesn't touch
> > > it from thereon in; there was some talk back in 1998 of fixing
> > > that, and patches were submitted but not included.
> >
> > First of all, I'm quite sure that mutt isn't the only mailer which
> > is paranoid about umasks.
> >
> > Second, on many systems you'll find lots of users who have whatever
> > loose umasks - which are frequently fine for most of the stuff they
> > are storing on the system, except e-mail. Think about it as mutt
> > failing on the safe side, that is, in favor of e-mail
> > confidentiality.
>
> I agree completely that it should fail on the safe side; I just want
> to see a "don't fail" option, and it seems straightforward to provide
> one.
>
> What I imagine is this: mbox_umask and attach_umask default to 077. If
> the user explicitly configures mbox_umask to be something else, that's
> used when creating mailbox files/maildirs. If the user explicitly
> configures attach_umask to be something else, then that's used when
> saving files which aren't mailboxes (and creating directories, should
> mutt ever do that outside of maildir/MH context). The exception to
> this would be temporary message files ready to be opened by an editor,
> which would always be 077. In other words, make it so that it can be
> configured user-by-user, rather than installation-by-installation as
> it is presently.
>
> Does that sound reasonable?
I would also want attach_umask to be applied before piping a message or
executing a shell command. I recently ran into this when I wanted to
pipe a message to a filter that would extract the attachments to a
directory for perusal. I had to add a wrapper to change the umask since
the same restrictive 077 umask remains set for all shell operations.
> -Rich
Mike
--
Mike Broome
[EMAIL PROTECTED]
