Add support for handling archive permisions on hardened servers

[ghorsman]

The module downloads the file as the puppet user (in this case root) and then attempts to untar the module as the confluence user. This fails if the server is hardened and restricts permissions on downloaded files. We have to work around this by adding the following heira:

system::execs:
    chown_jira_tarball:
        command: /bin/chown -R confluence:confluence /opt/staging/
        unless: /usr/bin/stat -c "%U:%G" /opt/staging/jira/atlassian-confluence-5.7.4.tar.gz | /bin/grep confluence:confluence
        require: Staging::File[atlassian-confluence-5.7.4.tar.gz]
        before: Exec[extract atlassian-confluence-5.7.4.tar.gz]

It would be good if the module handled this itself by explicitly ensuring the archive permission are correct before attempting the extract.

This is also the case for confluence and I'll raise it there as well.

[igalic]

@ghorsman can you provide a patch to the module?

[mkrakowitzer]

@igalic I will look at this issue for all the Atlassian modules.
Possibly it can be resolved with some additional parameters being specified to the staging class.

@ghorsman Can you give me any specifics on how I could reproduce this issue? just give me some pointers on the os settings used to harden to the system to reproduce the issue.

[jyaworski]

Hello: What's the status of this?

[Cinderhaze]

We have a similar problem with it. We have added a umask parameter to our staging::file and staging::extract modules (to set it to 022 for all execs). In our case, our hardening had set the umasks to 077 which rendered the files put in place unreadable. This was a problem when run by any user other than root.

A more direct way of passing permissions would be preferable, but I could possibly recommend the addition of a umask param to staging::file and staging::extract

We have also had similar problems with the default /opt/staging directory that gets created