|
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.