Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANTw=MP2uKg9TAVGUjMSb4zG-MTY9BcYK2HDa2HfXSAytNm_xQ@mail.gmail.com>
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.