"Laszlo Boszormenyi (GCS)" <g...@debian.hu> writes: >> The current stable is >> 3.7.3-1 and doesn't have this bug. The current testing is 3.7.13-1 and >> it does have the bug. The next stable would be better with a patched >> 3.7.13 or 3.7.16. > I can ask Release Managers. Freeze is in effect for a while and some > days ago it became deep freeze. While this bugfix seems very important, > you are the only one who's affected. Especially when you see that the > testing version is available for stable as well.
I suspect most people affected by this don't realise they are affected. Nobody writing a multi-threaded application expects a library to change umask because such a change cannot be reliable. The SQLite code doesn't even work reliably for multiple threads using SQLite. This works: thread 1: set umask to 0 storing old non-zero umask thread 1: create file thread 1: set umask to stored non-zero value this fails: thread 1: set umask to 0 storing old non-zero umask thread 2: set umask to 0 storing old 0 umask thread 1: create file thread 2: create file thread 1: set umask to stored non-zero value thread 2: set umask to stored 0 value That changes the umask of the process to 0 and forgets the non-zero value. >> This bug can cause multi-threaded servers to create files with world >> read/write access. > [...] >> Any files created by other threads in that apache process while the >> umask is 0 will be world read/write by default. > Do you get any word writable files then or it's just a possibility? An application that creates files will generally explicitly set permissions, say 600, or will rely on "umask permissions" (permissions masked with the current umask). An application that creates files with specific permissions will probably not be affected. The more usual case is to create files with umask permissions and in those cases it comes down to timing: if the file is created while the umask is 0 the file will be world read/write. It's not just SQLite files that get wrong permissions, it's any file created with umask permissions. -- Philip -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
