Question of File Templates and what I may be doing wrong

Automation/IaC
,
1

Hello!

I’m attempting to user a few File Templates to drop some files on systems being provisioned in our vSphere environment, but I’m hitting an issue where the File Templates process appears to set the file permissions as what looks like 775, but beyond that is adjusted the permissions of all files in the folder recursively, such as /etc/ where I’m dropping an /etc/krb5.conf

I realized this as sudo was barking that sudo.conf is group writable, and sshd fails to run because the private keys are set with the wrong permissions.

An example of what I did was:

Name: /etc/krb5.conf
File Name: krb5.conf
File Path : /etc
Phase: provision (also attempted pre-provision)
File Owner: root
Settings Name:
Settings Category:
Template:

Most of the pre-setup options in Morpheus have just the directory as the File Path, as do the two Morpheus Videos I watched prior, but I did notice the build in “app armoar mysqld config” is setup as:

  • Name app armor mysqld config
  • File Name usr.sbin.mysqld
  • File Path /etc/apparmor.d/local/usr.sbin.mysqld

For the file path, should I put the full file path and not just the directory? Also, for the File Owner field can I do “root:root” or is it just the User part of file ownership?
Lastly, is there any way to set the octal permissions values via the File Templates method?

Thanks!

2

Hi,

You are running into the same problems and questions I ran into with File Templates when creating a “/etc/issue” file on a system. I tried to address this in June of 2024 as a security issue via support ticket 206818. My observations:

I had found out that the code that drops the File Template onto a system basically blatantly does this:

chown root:morpheus-node “File Path”
chmod -R u+rwx,g+rwx,o+rx “File Path”

Which in the case of a file in /etc or other system folders is a very very bad thing and causes system daemons like SSH to complain or simply refuse to function as you experienced.

The response from support was:

I have been informed this is by design as the folder permissions need to be changed to allow the write into the folder.

To accomplish this into a folder like /etc I would suggest you add the file in a different location and then use a task to adjust the file permissions as needed and move the file to the desired folder.

I think this is not a proper response: The Morpheus Agent has the ability to execute commands as root (otherwise it couldn’t change the permissions of folder ‘/etc’ to begin with), so in the case of dropping File Templates it should be able to drop the file without the need to change permissions of any existing folders. The only permissions it would need to touch are those of non-existent folders it might need to create and the file itself. To my knowledge this part of the ticket is left unaddressed as the ticket was closed and this specific item was not set through to the development team for consideration of being fixed. Which reminds me to take this one up with our Account Manager.

In the same ticket I addressed the undocumented feature of being able to use “owner:group” and have the documentation and/or input hint be adjusted to show that format is permissible. This is supposedly a new case and with the Dev team. But I can’t see/track this specific new case. As of 7.0.6-2 the issue is still present.

A third item I tried to address in that ticket was that there is no way to set sane permissions on the file you are trying to create on the file. Which can be a security issue depending on the file being created and how long there is between the file being dumped on the system and a Task being run to fix the deficiencies in the File Template drop code. This is supposedly a new case as well and with the Dev team. But I can’t see/track this specific new case. As of 7.0.6-2 the issue is still present.

And lastly another item I tried to address regarding File Templates in this ticket (which was pulled out into a separate ticket 206885) was the fact the file contents all empty lines removed from the beginning and end of the file plus the final CR&LF stripped from what you enter in the Template input for the File Template. The response in ticket 206885 was:

After review of this by the development team it was determined to not be something that will be changed. String autotrim is system wide. A FILE template should not care about whitespace in general and trim is considered acceptable.

All these issues made the File Template feature unusable for dropping a file as simple as /etc/issue or /etc/motd on a UNIX system.

Two notes on your “Phase” question:

  1. You likely want to use “Provision” as the phase because “Pre-Provision” would attempt to drop the file on a still non-existent vm/server.
  2. There is a gotcha if you want to use ‘Post Provision’ as the phase: The Post-Provisioning phase is triggered for all nodes (aka vms, servers, or compute) of an Instance when a scale event occurs and the added node enters the Post-Provisioning Phase. I’m assuming that File Templates deployments only trigger on the newly added/deployed node but any ‘fix’ tasks needed because of the earlier discussed issues would be triggered on all nodes in an Instance. If this is the case, your fix Tasks need to be made re-entrant safe. Shameless plug for a vote: I opened a feature request to ‘fix’ this behavior by adding more Phases: Separate "Scale Up" Stage in Provisioning Workflow Needed

On your question regarding the file path: that, to my knowledge, should always be the full absolute path from the root.

-Yaron.