Your message dated Sun, 12 Feb 2017 22:47:09 +
with message-id
and subject line Bug#832908: fixed in mongodb 1:2.4.10-5+deb8u1
has caused the Debian Bug report #832908,
regarding mongodb: CVE-2016-6494: world-readable .dbshell history file
to be marked as done.
This means that you claim that
Your message dated Tue, 09 Aug 2016 22:26:49 +
with message-id
and subject line Bug#832908: fixed in mongodb 1:2.6.12-3
has caused the Debian Bug report #832908,
regarding mongodb: CVE-2016-6494: world-readable .dbshell history file
to be marked as done.
This means that you claim that the
Please try to persuade upstream for the fix in https://groups.google.co
m/forum/#!topic/mongodb-dev/-QR4B7PJ9YY
Thanks,
Marek
On Wed, 3 Aug 2016 23:32:02 +0200 Ola Lundqvist wrote:
> Hi Jérémy, Laszlo and LTS team
>
> You have probably seen my latest emails about "Bug#832908:
Hi Jérémy, Laszlo and LTS team
You have probably seen my latest emails about "Bug#832908: mongodb:
CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade
handling".
I have now prepared a security update of this CVE-2016-6494 and in addition
to that TEMP-0833087-C5
Hi Chris
I had this
// Make sure this file is not readable by others
But maybe it was not clear enough. :-)
// Ola
On Wed, Aug 3, 2016 at 12:00 AM, Chris Lamb wrote:
> > This is why I just override the "world readable" part and
> > let the rest be controlled by the user.
>
> Ah, didn't quite
> This is why I just override the "world readable" part and
> let the rest be controlled by the user.
Ah, didn't quite spot you are overriding just this bit. Worth a comment
I think.
> In the working patch you can see that I also set back the umask (just a
> little further down in the file) as it
Hi Chris
The reason I do not simply set the umask to a fixed value is to use the
same principle as upstream. That is honor the umask set bu the user. There
may be reasons why group read and/or write should be set for example.
I agree with upstream that the umask should be honored, but not as stri
> Here is the working patch (attached).
Out of interest, why:
+mode_t prev_mask = umask(0022);
+// Make sure this file is not readable by others
+umask(prev_mask | S_IROTH | S_IWOTH | S_IXOTH);
FILE *fp = fopen(filename,"w");
.. over, say:
+// Make sure this file is not rea
Hi again
Here is the working patch (attached).
Hope it helps for later versions too.
// Ola
On Tue, Aug 2, 2016 at 12:15 AM, Ola Lundqvist wrote:
> Hi again
>
> I just realize that we need to change back the umask after the file is
> created. I'll update the patch tomorrow and send one that I
FWIW, the vendor has closed https://jira.mongodb.org/browse/SERVER-25335
with "Works as Designed".
If someone wants to follow up on explaining to mongodb upstream why
umask shouldn't prevent them from applying proper permissions where
needed, they're welcome to do so. ssh-keygen(1) would be a good
Hi again
I just realize that we need to change back the umask after the file is
created. I'll update the patch tomorrow and send one that I know works.
// Ola
On Tue, Aug 2, 2016 at 12:13 AM, Ola Lundqvist wrote:
> Hi all
>
> I have prepared a preliminary patch for wheezy. I have not yet been
y others.
Author: Ola Lundqvist
Origin: other
Bug: https://jira.mongodb.org/browse/SERVER-25335
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832908
Forwarded: no
Reviewed-By: Ola Lundqvist
Last-Update: 2016-08-01
Index: mongodb-2.0.6/third_party/linenoise/linenoise.cpp
===
> 2) How do you plan to handle the "upgrade case" that is will you try to
> change the permission on already created history file or will you just
> handle the creation case?
For redis, what I did was set and then unset the umask (for creation) and
chmod(2) the file afterwards to "upgrade" existin
Hi
I'm member of the Long Term Security team in Debian and I'm following this
as I plan to backport the correction to wheezy.
I have a few questions:
1) When do you think you will have a correction available that I can have a
look at?
2) How do you plan to handle the "upgrade case" that is will y
On Sat, Jul 30, 2016 at 05:53:10AM +, 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 user
On Sat, Jul 30, 2016 at 4:50 AM, kpcyrd wrote:
> So, upstream just closed the issue I created with 'Works as Designed'
> blaming the default umask for the bug and that specifying file
> permissions for files created by mongodb is not something mongodb should
> do.
>
> https://jira.mongodb.org/brow
So, upstream just closed the issue I created with 'Works as Designed'
blaming the default umask for the bug and that specifying file
permissions for files created by mongodb is not something mongodb should
do.
https://jira.mongodb.org/browse/SERVER-25335#comment-1342085
The bug is locked, what do
Processing commands for cont...@bugs.debian.org:
> tags 832908 + upstream
Bug #832908 [mongodb-clients] world-readable .dbshell history file
Added tag(s) upstream.
> forwarded 832908 https://jira.mongodb.org/browse/SERVER-25335
Bug #832908 [mongodb-clients] world-readable .dbshell histor
Package: mongodb-clients
Version: 2.4.10-5
Severity: grave
Tags: security
During the report on redis-tools
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832460), lamby@
linked to a codesearch and the same bug was found in mongodb-clients.
mongodb-clients stores its history in ~/.dbshell, thi
19 matches
Mail list logo
