Override default directory permission of 700 as of 3.21 #5484
-
Hi all In https://cfengine.com/blog/2022/change-in-behavior-default-directory-permissions-now-700/ we see that as of 3.21, CFEngine uses a more restrictive set of permissions when it creates a directory (creates as 700 instead of 755 as before) We have a couple of places where we use bodies in the CFEngine library to do get some things done, and their behavior has of course changed as of 3.21 and this new default directory permission. I'm trying to find a way to change this default behavior so that if CFEngine creates a directory for me in the course of fulfilling a promise, I can specify what the permission of that directory should be. My two examples:
If I pass in
where
In this case the new directory ccontaining the Is there a straighforward way using existing body types to ensure that when CFEngine creates a directory while fulfilling a promise, that it has a permission that I specify rather than the default? The linked behavior change blog post didn't come with any suggestions for those of us hwo found that we were dependent on the more permissive behavior of versions prior to 3.21. Thanks in advance for any suggestions! Jay |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 4 replies
-
Hi Jay
Is the behavior in 3.21 a problem? I believe prior to 3.21 the directory would be created with 755, but then it would be changed to 444. Now after 3.21 it should as you note get created with the permissions specified (if my memory is correct). Oh, never mind. It's recursive, so I think the perms explicitly stated apply only to the files copied, not to directories created where those files live. I wonder about 2 promises. One to recursively copy directories only (file_select) another to then copy the files into place. I am not sure off the top of my head.
Looks like a typo: MMM, this one I think you would need a different promise to specify the permissions of directories leading to So you could do something like (completely untested and no warranty given, all of your blown up servers are belong to you):
There is not (currently) a global default that can be set to default the permissions of newly created directories that are not explicitly promised. But, it could be considered. Perhaps file a ticket on the public bug tracker? Also, generally PRs welcome :D |
Beta Was this translation helpful? Give feedback.
-
What I did in the SCL library is written my own copy_from body:
```
body perms scl_mog(mode, user, group, rxdirs_flag)
{
groups => { "$(group)" };
mode => "$(mode)";
owners => { "$(user)" };
rxdirs => "$(rxdirs_flag)";
}
```
The `rexdirs` is true then directories that are created have also the
`x` flag. There is no standard in the current cfengine library I believe.
Regards
Bas
…On 23/04/2024 23:22, Nick Anderson wrote:
Hi Jay |o/|,
* I see a typo here, |recurse| not |recurs|
1 syncing a directory from a source to a target where the target
directory does not already exist:
files: "$(target_dir)/." create => "true", perms => "mog("$(mode)",
"${owner)", "$(group)"), depth_search => recurs("inf"). copy_from =>
copyfrom_sync($(source_dir));
If I pass in 444 as the mode and target_dir doesn't exist, then
target_dir was created with mode 755 prior to 3.21, and now is
created with mode 444 as of 3.21.
Is the behavior in 3.21 a problem? I believe prior to 3.21 the directory
would be created with 755, but then it would be changed to 444. Now
after 3.21 it should as you note get created with the permissions
specified (if my memory is correct). Oh, never mind. It's recursive, so
I think the perms explicitly stated apply only to the files copied, not
to directories created where those files live. I wonder about 2
promises. One to recursively copy directories only (file_select) another
to then copy the files into place. I am not sure off the top of my head.
2 copying a file from a source to a target there the target
directory does not already exist:
files: "$(target_file)" copy_from =>
backup_local_dcp("$(source_file)"), perms => "mog("$(mode)",
"${owner)", "$(group)");
where
body copy_from backup_local_dcp(from) { source => "$(from)",
copy_backup => "timestamp", preserve => "false", compare => "digest"; }
Looks like a typo: |${owner)|, think you mean |$(owner)| or |${owner}|.
MMM, this one I think you would need a different promise to specify the
permissions of directories leading to |$(target_file)|.
So you could do something like (completely untested and no warranty
given, all of your blown up servers are belong to you):
|bundle agent __main__ { files: # This only handles the directory in
which target_file lives. If you need # further up the chain, you would
need more. "$(with)/." with => dirname( "$(target_file)" ), perms =>
mog( "$(mode)", "$(owner)", "$(group)" ); "$(target_file)" copy_from =>
backup_local_dcp("$(source_file)"), perms => "mog("$(mode)", "${owner)",
"$(group)"); } |
Is there a straighforward way using existing body types to ensure
that when CFEngine creates a directory while fulfilling a promise,
that it has a permission that I specify rather than the default? The
linked behavior change blog post didn't come with any suggestions
for those of us hwo found that we were dependent on the more
permissive behavior of versions prior to 3.21.
There is not (currently) a global default that can be set to default the
permissions of newly created directories that are not explicitly
promised. But, it could be considered. Perhaps file a ticket on the
public bug tracker? Also, generally PRs welcome :D
—
Reply to this email directly, view it on GitHub
<#5484 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADJKB5UD27TAVCJQMX6G6DY63GJFAVCNFSM6AAAAABGVTHU6KVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TEMBVGY2DC>.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
--
Bas van der Vlies
| High Performance Computing & Visualization | SURF| Science Park 140 |
1098 XG Amsterdam
| T +31 (0) 20 800 1300 | ***@***.*** | www.surf.nl |
|
Beta Was this translation helpful? Give feedback.
-
Nick,
Thanks for the suggestion. Nice!
Regards
PS) one day I have to switch to the `scl:` namespace ;-)
…On 24/04/2024 21:16, Nick Anderson wrote:
Humm, that's a good thought. @jgoldber13 <https://github.com/jgoldber13>
did you try this?
I would just note you could use inherit if you want to use whatever the
settings in the stdlib are, but customized slightly.
|body perms scl_mog(mode, user, group, rxdirs_flag) { inherit_from =>
default:mog( "$(mode)", "$(user)", "$(group)" ); rxdirs =>
"$(rxdirs_flag)"; } |
—
Reply to this email directly, view it on GitHub
<#5484 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADJKBYUPQTVPYJD3C3VLILY7AAIBAVCNFSM6AAAAABGVTHU6KVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TEMJXGQ2TC>.
You are receiving this because you commented.Message ID:
***@***.***>
--
--
Bas van der Vlies
| High Performance Computing & Visualization | SURF| Science Park 140 |
1098 XG Amsterdam
| T +31 (0) 20 800 1300 | ***@***.*** | www.surf.nl |
|
Beta Was this translation helpful? Give feedback.
Hi Jay
o/
,recurse
notrecurs
Is the behavior in 3.21 a problem? I believe prior to 3.21 the directory would be created with 755, but then it would be changed to 444. Now after 3.21 it should as you note get created with the permissions specified …