The specified daemonUser is not the owner of the installation directory

[aparkinson]

Packages built not using root as the daemonUser don't have ownership or permissions to access the installation directory of the Application or Service.

The present workaround has been to provide a postinst file containing chown -R <user>:<group> /usr/share/<appname>

[muuki88]

Bash addition

This would be an easy option. Ordering in the postinst will be crucial:

# 1. Create all user (daemonUser, too)
...
# 2. Default chown
chown -R <user>:<group> /usr/share/<appname>
# 3. Custom packageMappings
chown <user>:<group> /usr/share/<appname>/specific/file

Altering packageMappings

The second option would be to alter the packageMappings. However it will be very hard to figure out what should be altered and what not. If we decided to alter every packageMapping (in Debian/Linux) this behavior must be configurable (turn off, do everything manually).

The big advantage is, that all folders that created are managed (e.g ``etc/defaultor/var/log/`)

Summary

I would go for option 2 as it is a more general approach, however this must be well documented as a lot of magic happens behind the scenes.

[aparkinson]

I agree with Option 2 as I did a little code investigation before filling the ticket. Option 1 was trivial to implement for the Server Archetype but I thought it could be brittle and there are a few TODO comments in the code for handling file ownership

[jsuereth]

Yeah, option #2 is what I think as well..

[kardapoltsev]

I think we should add another settings for user, because daemonUser shouldn't owned installation directory. It may be insecure, IMHO.

[muuki88]

@kardapoltsev . Can you go into more detail? The daemonUser will execute the application, so I must be able to execute the start script and read all other files. What would you suggest?

[kardapoltsev]

I think that daemonUser should be able to read files but not write. Since default permissions is 755, anybody could read files in install location.

[muuki88]

But with 755 this is always the. Independent of the daemonUser. Still there's room for improvement, I read a bit in on debian.org

• Best Practices for OS Security
• Creating users and groups for software daemons

Especially the second link is very useful. I will try to integrate some of this in our postinst-template.

[aparkinson]

I've started some basic work on this item but I would like a sanity check before I go to far down the rabbit hole.... see #139

[muuki88]

@jsuereth , should we create features branches directly in this repository or continue using our forks?

[jsuereth]

@muuki88 You can throw feature branches in this repo, that way it's a bit easier for us to coordinate together and share code. You can issue PRs against a feature branch easily too.

The only caveat is after a feature branch is merged, then we should ensure we delete it :)