deb postinst chmod more directories

[paddymahoney]

addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "0.7.0-M2")

In our app, we set the following sbt-native-packager keys:
appUser
appGroup
daemonUser

The postinst resulting from a debian:packageBin looks like:

...
chown appUser:appGroup /usr/share/projname/share/buildinfo/BuildInfo.scala
chown appUser:appGroup /usr/share/projname/bin/projname
chown appUser:appGroup /var/log/projname
chown appUser:appGroup /etc/default/projname
chown appUser:appGroup /etc/init/projname.conf
chown appUser:appGroup /usr/share/projname
chown appUser:appGroup /usr/share/projname/lib/de.waldheinz.fat32-lib-0.6.4.jar
chown appUser:appGroup /usr/share/projname/lib/org.json.json-20090211.jar
...

Certain directories that are part of the debian package are not chmod'ed.
Examples include
/usr/share/projname/lib
/usr/share/projname/bin

The issue being that the installing processes (apt, debian) are all run as root, and so the directories are then owned by root.
This causes problems when other processes owned by the appUser attempt to run and make modifications to these directories.

Could sbt-native-packager own these folders on behalf of the appUser?

[jsuereth]

cc> @muuki88 Looks like this should be fixed before the 0.7.0 final.

[aparkinson]

@muuki88 Wasn't there a decision at some point to not allow certain directories to be written to for security reasons?

[jsuereth]

@aparkinson ah, good point.

Maybe we should also document how to map over the owners of files in linux packages so that you can modify them, and that's how we "fix" this issue too.

[kardapoltsev]

Please, take a look at #170, and http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard.

/usr -- Secondary hierarchy for read-only user data; contains the majority of (multi-)user utilities and applications.[6]

I think we shouldn't allow to change permissions for /usr/share/app_name. If anybody want to do it, he could write it't own postinst script

[muuki88]

@kardapoltsev , @aparkinson and I discussed this very extensive and the current implementation is the one enforcing best-practice.

@paddymahoney can you give us some details on what you trying to achieve? If you want a writeable folder for your app the best thing is to create a new mapping to a specfied folder, e.g. /data/yourapp.

[paddymahoney]

@kardapoltsev @aparkinson @jsuereth I trust that this outcome is correct. We ran into some issues running the app, but I think that deserves another deeper investigation on our side. Sorry for the noise.

[muuki88]

No problem :) We are interested in user feedback to provide the best possible user-experience. So let us know when you figured it out

[paddymahoney]

I did eventually figure this out. Originally, I suspected the permissions were incorrect-not enough chowns. I guessed this because our application wouldn't run. In the end, I found that we had overridden the start script elsewhere-our new start script was bad. Thank you for having looked into this issue.