Ad I stand corrected on the significance of the umask here :-) I
overlooked the fact that the file was created if it didn't exist.
-Dan
On Feb 2, 2011, at 3:57 AM, Eystein Måløy Stenberg wrote:
> I looked into this, because it was taunted so "critical".
> You are exactly right, Seva.
>
Umm... "go+r" does not mean "mode = 044"! It means "add r to g and o" or in
other words, "mode = mode | 044". The umask should have nothing to do with it,
as that is only used for file creation, AFAIK.
As to why they said, "go+r" instead of "644" is anyone's guess :-)
-Dan
On Feb 2, 2011, at
I concur with Seva and Eystein that the problem is that the policy (relative
permission)
is itself insecure. Since you have not chosen to preserve the permissions of
the original
file, the safest thing to do is to start from no permissions. Using umask is
not at all a
good idea for a secure app
Hello,
Ok, so that's not a bug, but it works as intended. I have no problems
with that, but in that case you should clearly document it somewhere
and especially give some special upgrade notes.
What is indeed scary is the fact that there was an API change, that's
not backward compatible, and that
I looked into this, because it was taunted so "critical".
You are exactly right, Seva.
When a file does not exist, the default perms for it start out at 000
if you have a perms-attribute.
Applying "go+r" gives 044. Setting perms => "644" gives the desired effect.
If the file does exist, the existi
This is the default umask change, I guess. The mode "go+r" explicitly
means 044, so basically they get what they defined. Perhaps, earlier
versions started with default mode 600, so that go+r worked fine, but
now they have mode 000 by default.
I wonder, why not just specify mode 644 instead of go+
We've not seen or heard of anything like this from anyone else, but
we'll look into it. No code has changed here for quite a while. Please
tell us what OS you are running this on. There is always the possibility
of a build error.
On 02/01/2011 11:01 PM, Jean-Noël Rivasseau wrote:
> Hello,
>
> I
Hello,
I just upgraded to 3.1.4 (from 3.0.5) and am facing a critical bug
that breaks all our code. Basically the following promise:
files:
"/srv/${global.INTERNAL_REVERSED_DOMAIN}/hudson/plugins/text-finder.hpi"
copy_from => fastCopyFromRemote("${global.OVERMIND_HOST}",
"${globa
