* Luca BRUNO <lu...@debian.org>, 2012-02-11, 15:33:
+ try: + # make sure the cookie jar is not world-open + perm_mode = os.stat(self.filename).st_mode + if (perm_mode & (stat.S_IROTH | stat.S_IWOTH | stat.S_IXOTH)) > 0: + os.chmod(self.filename, (stat.S_IMODE(perm_mode) >> 3) << 3) + except OSError: + pass
I'm not sure it's appropriate to change permissions of existing files. I certainly don't like when software do that. (On the other hand, it's not much different than removing a file and then recreating it.)
What I did for another browser with similar vulnerability, was to leave permissions of existing files, and to ask (in NEWS.Debian) sysadmin to fix them manually. YMMV.
I find "((... >> 3) << 3" expression difficult to understand. I'm sure it could expressed in terms of S_* constants in a more readable way.
+ # restrict umask before creating the cookie jar + curmask=os.umask(0) + print (curmask|(stat.S_IROTH | stat.S_IWOTH | stat.S_IXOTH)) + os.umask(curmask|(stat.S_IROTH | stat.S_IWOTH | stat.S_IXOTH))
"stat.S_IROTH | stat.S_IWOTH | stat.S_IXOTH" could be written as "stat.S_IRWXO".
You revoke only read permissions for other, but having your cookie jar readable by group might be as bad.
It's probably a good idea to restore umask to the original value once the private files have been opened.
(The above remarks apply to other hunks as well.) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
