I'll add that somewhere between 3.0.5 and 3.2.0, the timing of when permissions were checked and enforced changed. In my case, this manifested itself when I had 'preserve => "true";' set in one my my copy_from bodies, but still had a 'perms=>' directive set in the promise.
The old behavior was that the permissions were copied from the server, then the 'perms=>' directive was applied. The new behavior reversed this, leading to unexpected permissions set on the clients. So there's definiately been something happening with how the 'order' of permissions-related stuff is applied in recent versions. I don't know if applies in this case, but perhaps it is related? On Wed, Dec 07, 2011 at 01:52:22PM -0500, no-re...@cfengine.com wrote: >Forum: CFEngine Help >Subject: Re: File mode checking promise state? >Author: sauer >Link to topic: https://cfengine.com/forum/read.php?3,24219,24222#msg-24222 > >neilhwatson Wrote: >------------------------------------------------------- >> The promise is to examine the checksum of the >> promiser file. There is no promise regarding the >> outcome of that check. > >Apoligies extended up front for the long message. :) > >My interpretation is that the promise is that the stats on the file will match >that which is in the database. If the database is updated, that's a repair. >Here's the verbose output: > > >cf3> -> Using literal pathtype for /tmp/x >cf3> -> Handling file existence constraints on /tmp/x >cf3> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >cf3> ALERT: Permissions for /tmp/x changed 100700 -> 100750 >cf3> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >cf3> -> File permissions on /tmp/x as promised >cf3> ?> defining promise result class _tmp_x_ok >cf3> -> Handling file existence constraints on /tmp/x >cf3> -> File permissions on /tmp/x as promised >cf3> ?> defining promise result class _tmp_x_ok >cf3> -> Handling file existence constraints on /tmp/x >cf3> -> File permissions on /tmp/x as promised >cf3> ?> defining promise result class _tmp_x_ok > > >It's saying that the permissions are as promised, but that's seemingly only >because the permissions seem to be checked after the database is updated. :) > >If my expectations are inaccurate, though, then the behavior when I change >"stats" to "contents" is wrong: > > >user@host >$ ./tripwire.cf > !! File /tmp/x was not in sha1 database - new file found >I: Made in version 'not specified' of './tripwire.cf' near line 8 >R: /tmp/x was ok >R: /tmp/x was fixed >user@host >$ echo blah > /tmp/x >user@host >$ ./tripwire.cf >!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >ALERT: Hash (sha1) for /tmp/x changed! >!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > -> Updating hash for /tmp/x to SHA=4cbd040533a2f43fc6691d773d510cda70f4126a >I: Made in version 'not specified' of './tripwire.cf' near line 8 >R: /tmp/x was ok >R: /tmp/x was fixed >user@host >$ ./tripwire.cf >R: /tmp/x was ok >user@host >$ echo moo > /tmp/x >user@host >$ ./tripwire.cf >!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >ALERT: Hash (sha1) for /tmp/x changed! >!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > -> Updating hash for /tmp/x to SHA=7a788f56fa49ae0ba5ebde780efe4d6a89b5db47 >I: Made in version 'not specified' of './tripwire.cf' near line 8 >R: /tmp/x was ok >R: /tmp/x was fixed > > >Actually, it looks like the contents behavior is arguably even more >inconsistent, as it marks the promise as being repaired and then notes that >the permissions are ok - even though I've specified that only contents should >be checked (I used the body from above and only changed "stats" to >"contents"). Here's the verbose output from that right after changing the >file's contents: > > >cf3> ========================================================= >cf3> files in bundle a (1) >cf3> ========================================================= >cf3> >cf3> >cf3> ......................................................... >cf3> Promise handle: >cf3> Promise made by: /tmp/x >cf3> ......................................................... >cf3> >cf3> -> Using literal pathtype for /tmp/x >cf3> -> Handling file existence constraints on /tmp/x >cf3> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >cf3> ALERT: Hash (sha1) for /tmp/x changed! >cf3> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >cf3> -> Updating hash for /tmp/x to >SHA=4cbd040533a2f43fc6691d773d510cda70f4126a >cf3> I: Report relates to a promise with handle "" >cf3> I: Made in version 'not specified' of './tripwire.cf' near line 8 >cf3> ?> defining promise result class _tmp_x_fixed >cf3> ?> defining promise result class _tmp_x_fixed >cf3> ?> defining promise result class _tmp_x_fixed >cf3> -> Persisent state checksum_alerts is already in a preserved state -- 3 >minutes to go >cf3> -> File permissions on /tmp/x as promised >cf3> ?> defining promise result class _tmp_x_ok >cf3> -> Handling file existence constraints on /tmp/x >cf3> -> File hash for /tmp/x is correct >cf3> ?> defining promise result class _tmp_x_ok >cf3> -> File permissions on /tmp/x as promised >cf3> ?> defining promise result class _tmp_x_ok >cf3> -> Handling file existence constraints on /tmp/x >cf3> -> File hash for /tmp/x is correct >cf3> ?> defining promise result class _tmp_x_ok >cf3> -> File permissions on /tmp/x as promised >cf3> ?> defining promise result class _tmp_x_ok > > >See how it raises the repaired class, and then checks permissions and further >raises the ok class? Weird. > >When I then change "content" to "all", it adds an additional modification time >check, but otherwise behaves the same way as the stats check - changing only >the modification time is treated as promise kept, changing only the >permissions is treated as kept, but changing contents is treated as both >repaired and kept. :) > >So, if there's something I can do in the policy to at least make this >consistent, that'd be neat. :D > >_______________________________________________ >Help-cfengine mailing list >Help-cfengine@cfengine.org >https://cfengine.org/mailman/listinfo/help-cfengine -- Jesse Becker NHGRI Linux support (Digicon Contractor) _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
