Proposal: enforce masterfiles permissions (0600) only on input_name_patterns

[Moore, Joe]

I have maintenance scripts in masterfiles, such as commit hooks and testing scripts.  On every policy hub, (where masterfiles is a checkout) the first time update.cf runs, the executable bits are stripped off by https://github.com/cfengine/masterfiles/blob/master/cfe_internal/update/update_policy.cf#L158, so the policy hub can’t (for example) have its own hooks run.

 

I believe that this would be a very small change in both code and impact:

* Files that match input_name_patterns (policy) will still be the only ones copied to clients by default. (clients would never see masterfiles/hooks/post-merge.githook)

* Files that do not match that pattern (not policy) will only be found on the am_policy_hub systems.  (masterfiles/hooks/post-merge.githook would keep its +x bit)

* The policy writer (me) would be responsible to set permissions on anything else in the masterfiles that ISN’T policy.  (If I want /etc/cshrc copied from masterfiles/distrib/cshrc, I should set the permissions explicitly)

 

The code change would be to add a file_select attribute to the “$(master_location)/.” promise, referencing the same

body file_select u_input_files as in the copy promise just above it.

 

I can't think of a way to change the behavior except by editing the forbidden cfe_internal files (hence, a 1-line pull request can be made)

 

What do you think?  Useful?  Insecure?  ???

 

Thanks,

--Joe

[mike.w...@verticalsysadmin.com]

Hi Joe,

I don't know about your exact situation, but I will tell you how I handled a related situation myself.

I wanted to distribute a script to hosts, "cf-info," to display basic diagnostic information.  The purpose was to have a single easy starting point for debugging host issues related to CFEngine.  It displays the CFEngine package version, the CFEngine policy version, the "ps" information on the CFEngine daemons running, the time since the last cf-agent run and how long the run took, and the promise outcome summary from that run—and a couple more things specific to the environment I'm working in.

Putting it directly in the masterfiles would mean that the execute bit would be stripped, but even more than that, the file wouldn't be copied out at all since it doesn't match the file suffixes specified in the "update" policy.  So instead, I named the file "cf-info.sh" so it would be copied out, made it non-executable since the execute bit would be stripped out anyway, and added a "files" promise to ensure the existence of "/var/cfengine/bin/cf-info" with contents identical to the script file from "inputs" and with the executable bit set.

---

You might also be interested in alternative methods of copying policy files out in the first place, as discussed in https://tracker.mender.io/browse/CFE-2058.

Hope that's helpful.  :)

Best,

--Mike Weilgart

Vertical Sysadmin, Inc.

[Moore, Joe]

I solved this a different way:

 

in def.json, I defined the var "masterfiles_perms_mode": "u+rw,g-w,g+r,o-rwx"

 

This makes sure that the files are read/write for owner (root), but does not touch the executable bit.  It makes sure the file is readable by the group (also root) but not writable, and again does not touch the executable bit.  And it takes away any permissions available for "everyone else".

 

In the process, I learned that you can put a character string for file permission promises, in a format similar to what is used by chmod.  The biggest difference being that you can not use an = to fully-specify the permissions symbolically.  (   error: ./perms.cf:0:0: In attribute 'mode', Scalar value is out of range. Given attribute value 'u=rw,g-w,g+r,o-rwx'  )

 

--Joe

--
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to help-cfengin...@googlegroups.com.
To post to this group, send email to help-c...@googlegroups.com.
Visit this group at https://groups.google.com/group/help-cfengine.
For more options, visit https://groups.google.com/d/optout.

[Moore, Joe]

I let this problem drop off my radar for a bit, but with the 3.10 LTS release, it came back up.  Two things to note:

 

1)      You are now allowed to specify permissions with an '=' symbolically. (yay)

2)      update.cf still does not respect the value of masterfiles_perms_mode from the augments file(s).  In controls/update_def.cf, input_name_patterns is defined with various ifvarclass expressions to implement augments, but none of the other variables are.  masterfiles_perms_mode, dc_scripts, masterfiles_staging, etc. can not be overridden without changing MPF code.  The cfengine_internal_preserve_permissions is probably intended (documented) to handle this, but this class is never referenced as a condition.

 

It would be an interesting exercise to list the source=promise classes and variables (from cf-promises --show- ) and compare that to the parsed policy's conditions.  Wishlist: cf-promises --show-unused-vars and/or --show-unused-classes

 

--Joe