Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 24 Sep 2012 13:13:24 -0400
From: Michael Gilbert <>
Subject: Re: Re: Re: CVE request(?): gpg: improper file
 permssions set when en/de-crypting files

On Mon, Sep 24, 2012 at 4:42 AM, Tavis Ormandy wrote:
> I agree. Users do know how to use umask properly, but this isn't what umask
> is for. The umask for the low order bits are only applied if the program
> requested 0666, it's still the responsibility of the program to choose the
> appropriate permissions.
> Creating sensitive files with 0666 and then saying "set your umask" is just
> wrong.

Think about the complexity potentially involved to solve these issues
the right way.

First of all, gpg is not the only application that would need to be
"privacy-aware". Every single application that produces new files from
existing ones to propagate permissions from those original files to
the new ones, which would be pretty much everything.  In addition,
piping would need to be permissions-aware to achieve the following:

$ umask 077
$ touch sensitive-file
$ umask 022
$ cat sensitive-file > sensitive-file2
$ ls -l sensitive-file*
-rw------- 1 a a 0 Sep 24 13:09 sensitive-file
-rw------- 1 a a 0 Sep 24 13:09 sensitive-file2

Also, in the gpg case, what should be done when starting with a 644,
should the decrypted contents be 600 (acting more as a protective
parent), or should it respect the original permissions (irrespective
of the umask), or chose the more restrictive of both?

I'm not saying that these problems couldn't (or shouldn't) be solved,
but it seems like a daunting task.

Best wishes,

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.