[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 21 Sep 2012 17:47:48 -0400
From: Michael Gilbert <michael.s.gilbert@...il.com>
To: Kurt Seifried <kseifried@...hat.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: Re: CVE request(?): gpg: improper file permssions
set when en/de-crypting files
On Fri, Sep 21, 2012 at 5:19 PM, Michael Gilbert wrote:
> So, the point is that umask is more meant more as a fallback only when
> there isn't better info available to make the right permissions
> decision.
Although I think that interpretation would be a safer way to go about
things, but thinking about it more broadly, it may open a large can of
worms. Would such a situation in all other applications be considered
an exposure?
So another vim example
$ umask
0077
$ echo test > test
umask 022
$ vim test
:w test2
$ ls -l test2
-rw-r--r-- 1 a a 5 Sep 21 17:33 test2
Would this be an exposure since the user had original file permissions
were 600, and the derived file is now 644?
So anyway, I suppose this creates more questions than answers, but I
guess its worth thinking about. After all, what did the user really
expect? If they had intended that original file to be private, and
now its not, is that appropriate? Is it more appropriate to assume
all users know how to use umask appropriately?
Best wishes,
Mike
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.
