On Sat, Jul 30, 2016 at 05:53:10AM +0000, László Böszörményi (GCS) wrote: > While this is a real issue, I somewhat agree with upstream. Being a > system administrator for long time, I know as others should know: > - don't run sensitive services on a machine which can be accessed by > untrusted users, > - even on your regular box set your $HOME to 0700 and your umask to 0077. > In short, always expect the worst case and be prepared.
As a system administrator, I fully agree that systems should be setup this way. You might want to consider posting this here[1] and here[2]. [1]: https://bugs.debian.org/398793 [2]: https://bugs.debian.org/782001 As a software engineer, I have to disagree here. You shouldn't assume your software is running on locked-down environments only. If a file might contain sensitive data, the file permissions should be set accordingly, after all, they are setting file permissions correctly on /var/lib/mongodb (even though they aren't setting them on /var/log/mongodb either). There are multiple use cases that might cause people to configure o+x permissions on home folders and it's also what default debian sets for home folders. I don't think blaming users that aren't unix wizards is the right way to deal with security, instead of having sane defaults towards security. The worst case should be the exception instead of the norm. If you run `ls -la ~/.*_history` most developers seem to agree with this, given that permissions are set correctly regardless of the umask. > > https://jira.mongodb.org/browse/SERVER-25335#comment-1342085 > > > > The bug is locked, what do I do now? > You mean what to do with upstream? I guess nothing. Probably I can > fix this myself. Please go ahead. This would resolve CVE-2016-6494 for the binary debian is distributing, but there are still various downstreams for mongodb on debian and MongoDB Inc themself that would ship without a patch. Thanks.
