[aur-general] Software packaging - Security question
Hi I am trying to create a package for the subvein[1] game. Installation instructions[2] of the game tell to simply uncompress the tar.gz archive in a folder and run the "Subvein" program. No problem with that. But then when running the game, it tries to store information in it's "data" folder (logs, configuration, user profiles...). We have a permission problem. To workaround this problem, I: - Create a group named "subvein"; - set the setgid bit for the game "data" folder and all it's sub-folders; - set the game "data" folder and all it's content group writable; - set the group of the game "data" folder to the "subvein" group. - Created a wrapper bash script that changes the umask to 002 and then launches the game. This way, all the contents created by the game will belong to the "subvein" group and will be group writable, so that anyone can use the game. Is this a valid way of doing it? Are there any security concerns I need to take into account? The game has also a "server" part. I still didn't started to handle this in the package, but was thinking to do the following: - Create a user names subvein that belongs only to the subvein group. - Create a systemd .service file that runs the server program as the subvein user. Does this seems OK as approach? Thank you for your help. P.S. You can find my "draft" of the PKGBUILD, the install script and the bash wrapper attached. [1] http://subvein.net/ [2] http://subvein.net/download.php -- Nuno Araujo <nuno.araujo@russo79.com>
Hi
I am trying to create a package for the subvein[1] game.
Installation instructions[2] of the game tell to simply uncompress the tar.gz archive in a folder and run the "Subvein" program.
No problem with that. But then when running the game, it tries to store information in it's "data" folder (logs, configuration, user profiles...). We have a permission problem.
To workaround this problem, I: - Create a group named "subvein"; - set the setgid bit for the game "data" folder and all it's sub-folders; - set the game "data" folder and all it's content group writable; - set the group of the game "data" folder to the "subvein" group. - Created a wrapper bash script that changes the umask to 002 and
On Thursday, January 10, 2013 11:36:25 AM Nuno Araujo wrote: then
launches the game.
This way, all the contents created by the game will belong to the "subvein" group and will be group writable, so that anyone can use the game.
Is this a valid way of doing it? Are there any security concerns I need to take into account? In a multi-user environment this would fail, so the game save _should_ be kept under $HOME. Don't know if there's a good way to do it, though, maybe someone else could help with this.
The game has also a "server" part. I still didn't started to handle this in the package, but was thinking to do the following:
- Create a user names subvein that belongs only to the subvein group. - Create a systemd .service file that runs the server program as the subvein user.
Does this seems OK as approach?
I think this part is OK and nice :)
Thank you for your help.
P.S. You can find my "draft" of the PKGBUILD, the install script and the bash wrapper attached.
-- Felix Yan Twitter: @felixonmars Wiki: http://felixc.at
On 10. 01. 13 11:43, Felix Yan wrote:
This way, all the contents created by the game will belong to the "subvein" group and will be group writable, so that anyone can use the game.
Is this a valid way of doing it? Are there any security concerns I need to take into account? In a multi-user environment this would fail, so the game save _should_ be kept under $HOME. Don't know if there's a good way to do it, though, maybe someone else could help with this.
When you say this would fail in a multi-user environment, do you refer to some technical issue or it's just because (and I agree with you), things shouldn't be this way?
The game has also a "server" part. I still didn't started to handle this in the package, but was thinking to do the following:
- Create a user names subvein that belongs only to the subvein group. - Create a systemd .service file that runs the server program as the subvein user.
Does this seems OK as approach? I think this part is OK and nice :)
Great, thanks :-) -- Nuno Araujo <nuno.araujo@russo79.com>
On 10. 01. 13 11:43, Felix Yan wrote:
This way, all the contents created by the game will belong to the "subvein" group and will be group writable, so that anyone can use
On Thursday, January 10, 2013 11:59:22 AM Nuno Araujo wrote: the
game.
Is this a valid way of doing it? Are there any security concerns I need to take into account?
In a multi-user environment this would fail, so the game save _should_ be kept under $HOME. Don't know if there's a good way to do it, though, maybe someone else could help with this.
When you say this would fail in a multi-user environment, do you refer to some technical issue or it's just because (and I agree with you), things shouldn't be this way? I think game saves of one user should not be accessible by others, as most games nowadays treat it this way :)
-- Felix Yan Twitter: @felixonmars Wiki: http://felixc.at
On 10 January 2013 11:43, Felix Yan <felixonmars@gmail.com> wrote:
On Thursday, January 10, 2013 11:36:25 AM Nuno Araujo wrote:
Is this a valid way of doing it? Are there any security concerns I need to take into account?
In a multi-user environment this would fail, so the game save _should_ be kept under $HOME. Don't know if there's a good way to do it, though, maybe someone else could help with this.
I think UnionFs can be used for this. I never actually tried it, but it should allow you to mount the data directory read only and then mount a RW directory from $HOME on top of, so all changes will be stored in the home directory.
On 10. 01. 13 12:25, Lukas Jirkovsky wrote:
I think UnionFs can be used for this. I never actually tried it, but it should allow you to mount the data directory read only and then mount a RW directory from $HOME on top of, so all changes will be stored in the home directory.
Thanks Lukas! I just tried it (manually, not yet packaged? and it works perfectly! :-) It bothers me to have to add a dependency on an fully unrelated package, but I think this is cleaner and safer than my previous solution. The only concern that I have with this approach, it's when the package gets upgraded. subvein seems to update some of it's own packaged files (at least translation files) when running. If suddenly, there is a new version of the modified files when upgrading, they won't be taken into account, since the priority will be given to those in the user $HOME. Well, I can display a warning message when upgrading the package, so that the user removes the files in it's $HOME folder. After all, this is Arch Linux, a distribution who targets and accommodates competent GNU/Linux users by giving them complete control and responsibility over the system. :-) Thank you for your help everyone! -- Nuno Araujo <nuno.araujo@russo79.com>
participants (3)
-
Felix Yan
-
Lukas Jirkovsky
-
Nuno Araujo