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 application. I would enforce an absolute permission as
Seva
suggests to make this right.
Earlier the semantics of this might have been different, but I believe the
current
approach is the most "correct" in the sense that it is the safest bet.
On 02/02/2011 09:57 AM, Eystein Måløy Stenberg wrote:
> 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 existing perms are taken as the starting point.
>
> Please be careful about messages like "everything is broken",
> "critical bug", etc, because it scares people that don't know the
> details.
> Personally, I would definitely not call this a critical bug, and am a
> bit uncertain if it's a bug at all.
>
> --
> Regards,
> Eystein
>
> On Wed, Feb 2, 2011 at 8:32 AM, Seva Gluschenko
> <seva.glusche...@gmail.com> wrote:
>> 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+r, btw?
>>
>> 2011/2/2 Mark Burgess <mark.burg...@iu.hio.no>:
>>>
>>> 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 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}",
>>>> "${global.UNISON_REPOSITORY_PATH}continuous-build/hudson/text-finder-1.8.hpi"),
>>>> perms => tomcat;
>>>>
>>>> where:
>>>>
>>>> body perms tomcat()
>>>> {
>>>> owners => {"tomcat"};
>>>> groups => {"tomcat"};
>>>> mode => "go+r";
>>>> }
>>>>
>>>> body copy_from fastCopyFromRemote(server, path)
>>>> {
>>>> servers => {"${server}"};
>>>> encrypt => "false";
>>>> trustkey => "true";
>>>> source => "${path}";
>>>> compare => "digest";
>>>> preserve => "false";
>>>> verify => "false";
>>>> purge => "true";
>>>> copy_backup => "false";
>>>> }
>>>>
>>>> does not create correct permissions on the copied file. It should have
>>>> a final permission of 644 but ends with 044:
>>>>
>>>> community> -> Copy file
>>>> /srv/net.kameleoon/hudson/plugins/text-finder.hpi from
>>>> /srv/net.kameleoon/unison/design-engine/overmind/continuous-build/hudson/text-finder-1.8.hpi
>>>> check
>>>> community> Connection to 91.121.223.125 is already open and ready...
>>>> community> -> /srv/net.kameleoon/hudson/plugins/text-finder.hpi
>>>> wasn't at destination (copying)
>>>> community> -> Copying from
>>>> overmind.kameleoon.net:/srv/net.kameleoon/unison/design-engine/overmind/continuous-build/hudson/text-finder-1.8.hpi
>>>> community> -> Copy of regular file succeeded
>>>> /srv/net.kameleoon/unison/design-engine/overmind/continuous-build/hudson/text-finder-1.8.hpi
>>>> to /srv/net.kameleoon/hudson/plugins/text-finder.hpi.cfnew
>>>> community> -> Owner of
>>>> /srv/net.kameleoon/hudson/plugins/text-finder.hpi was 0, setting to
>>>> 265
>>>> community> -> Group of
>>>> /srv/net.kameleoon/hudson/plugins/text-finder.hpi was 0, setting to
>>>> 265
>>>> community> -> Object
>>>> /srv/net.kameleoon/hudson/plugins/text-finder.hpi had permission 600,
>>>> changed it to 644
>>>> community> -> Updated file from
>>>> overmind.kameleoon.net:/srv/net.kameleoon/unison/design-engine/overmind/continuous-build/hudson/text-finder-1.8.hpi
>>>> community>
>>>> Performance(Copy(overmind.kameleoon.net:/srv/net.kameleoon/unison/design-engine/overmind/continuous-build/hudson/text-finder-1.8.hpi
>>>>> /srv/net.kameleoon/hudson/plugins/text-finder.hpi)): time=0.0114
>>>> secs, av=0.0109 +/- 0.0105
>>>> community> Existing connection just became free...
>>>> community> -> Handling file existence constraints on
>>>> /srv/net.kameleoon/hudson/plugins/text-finder.hpi
>>>> community> -> Owner of
>>>> /srv/net.kameleoon/hudson/plugins/text-finder.hpi was 0, setting to
>>>> 265
>>>> community> -> Group of
>>>> /srv/net.kameleoon/hudson/plugins/text-finder.hpi was 0, setting to
>>>> 265
>>>> community> -> Object
>>>> /srv/net.kameleoon/hudson/plugins/text-finder.hpi had permission 0,
>>>> changed it to 44
>>>>
>>>> This bug is critical for us, so if someone can look, it would be
>>>> appreciated (and this is a very dangerous bug).
>>>>
>>>> Thanks,
>>>> Jean-Noel
>>>> _______________________________________________
>>>> Help-cfengine mailing list
>>>> Help-cfengine@cfengine.org
>>>> https://cfengine.org/mailman/listinfo/help-cfengine
>>> _______________________________________________
>>> Help-cfengine mailing list
>>> Help-cfengine@cfengine.org
>>> https://cfengine.org/mailman/listinfo/help-cfengine
>>>
>>
>>
>>
>> --
>> SY, Seva Gluschenko.
>> _______________________________________________
>> Help-cfengine mailing list
>> Help-cfengine@cfengine.org
>> https://cfengine.org/mailman/listinfo/help-cfengine
>>
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@cfengine.org
> https://cfengine.org/mailman/listinfo/help-cfengine
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
