Re: Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling

On Wed, Aug 03, 2016 at 12:25:32AM +0200, Ola Lundqvist wrote: >Hi >Maybe. However if someone is added to a users group that should really >mean that they should at least be able to read things, even though they >may not be able to write to stuff. So I actually think bash and

Re: Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling

Hi Maybe. However if someone is added to a users group that should really mean that they should at least be able to read things, even though they may not be able to write to stuff. So I actually think bash and others do the wrong thing here. The way I have done it is also more in line with

Re: Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling

On 02/08/16 23:57, Ola Lundqvist wrote: > 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

Re: Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling

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

Re: Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling

> 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

Re: Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling

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

Re: Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling

> 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

Re: Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling

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

Re: Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling

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

Re: Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling

Hi all I have prepared a preliminary patch for wheezy. I have not yet been able to test it fully (it is building right now). It looks like attached. You may need to modify it for later versions. Please comment. The principles should be ok even if I may have made some stupid copy+paste mistake.

Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file: LTS update and upgrade handling

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