File Permissions - user isn't set?

[muuki88]

The FileUtil class provides a chmod object, but nothing for chown.

Is the user set anywhere in the build?

[jsuereth]

I don't think so. I think it's all "root" right now.....

[jsuereth]

So right now, the user is used primarily for RPM builds, where file permission info is external in the spec file:

https://github.com/sbt/sbt-native-packager/blob/master/src/main/scala/com/typesafe/sbt/packager/rpm/RpmMetadata.scala#L86

For debian, it seems sticking with root is the best practice: http://man.he.net/man1/dh_fixperms

I also learned i this process about /etc/skel which is a fun trick :)
In any case, here's more information from http://www.debian.org/doc/debian-policy/ch-files.html -

If you need to create a new user or group for your package there are two possibilities. Firstly, you may need to make some files in the binary package be owned by this user or group, or you may need to compile the user or group id (rather than just the name) into the binary (though this latter should be avoided if possible, as in this case you need a statically allocated id).

If you need a statically allocated id, you must ask for a user or group id from the base-passwd maintainer, and must not release the package until you have been allocated one. Once you have been allocated one you must either make the package depend on a version of the base-passwd package with the id present in /etc/passwd or /etc/group, or arrange for your package to create the user or group itself with the correct id (using adduser) in its preinst or postinst. (Doing it in the postinst is to be preferred if it is possible, otherwise a pre-dependency will be needed on the adduser package.)

On the other hand, the program might be able to determine the uid or gid from the user or group name at runtime, so that a dynamically allocated id can be used. In this case you should choose an appropriate user or group name, discussing this on debian-devel and checking with the base-passwd maintainer that it is unique and that they do not wish you to use a statically allocated id instead. When this has been checked you must arrange for your package to create the user or group if necessary using adduser in the preinst or postinst script (again, the latter is to be preferred if it is possible).

So, it looks like you need to reserve the UID you want files to be owned as, and you need to create such a user EITHER in the debian chain you're using or in the preinst script. So, if we allow the owner thing to work, we may want to provide warnings or some kind of indication that you need a post/pre-inst script that ensures the user exists.

SO - RPM is covered. Debian is not, but it looks like it is UID based.

Actions:

1. Add chown support to the debian builder (we use a tmproot thing, so we'll have to investigate how to set ownership appropriately in that.
2. See if we can provide a useful warning about non-root users. Maybe lintian and rpmlint will give us the warnings we want?

What do you think?

[muuki88]

Sorry for my late reply.

This link was really helpful and I think we can do as they propose.

When this has been checked you must arrange for your package to create the user or group
if necessary using adduser in the preinst or postinst script (again, the latter is to be
preferred if it is possible)

This would imply we append extra code at the end for preinst, postinst and postrm. This should't go without a warning during the build (as this is the kind of magic I fear ;) )

example appending for preinst

# check if user exists
...
# create if not existend
adduser ${username} ... options

example appending for postinst

# chown according to mapping which are non-root
chown ${username} ${path}
...

example appending for postrm

# delete user if exists
...

[jsuereth]

I agree we should try to make this happen. This looks like a decent plan. Thanks for the investigation! IF you get time before I do, let me know :)

[muuki88]

I will give it a try this weekend. I must correct by message before. We could put all stuff in the postinst. No preinst needed.

[jsuereth]

cool! Yeah, sounds like you may have time before me :)

[muuki88]

Can wie close this?

[jsuereth]

Sure. I think the RPM side already handle sthis too.