Feedback #5990
File/dir modes in game archive
Description
When unpacking KSP archive (with 'unzip ksp-linux-1-0-5.zip' or '7z x ksp-linux-1-0-5.zip') I get 775 mode for all dirs and files, despite current umask is default 0022, so mode is set explicitly in the archive.
By common sense, modes should be 755 for dirs, 644 for files and 755 for executables.
History
#1
Updated by sal_vager about 9 years ago
Updated by Nevermind, going to test this some more.
#2
Updated by psycho_zs about 9 years ago
Updated by Zip can not preserve full permissions, but it can at least preserve mode.
touch file chmod 775 file zip file.zip file rm file unzip file.zip stat -c %a file
#3
Updated by sal_vager about 9 years ago
- Tracker changed from Bug to Feedback
- Category changed from Application to 369
- Severity changed from Low to Very Low
Okay I think I know what's doing this.
The devs all use Windows PC's to make KSP, including to zip KSP for release to the store (Steam, GoG and Amazon repack KSP with their own installer).
Zip itself doesn't have any commands to set the permissions of the files it contains, and just stores the perms from the host, as does 7z.
Windows equivalent umask is 002, so they go in the zip and it unzips with those attributes, zip doesn't actually take the destination machines umask into account, I tested a bunch of game zips and some text files with various permissions and they all unzip with whatever permissions they were zipped with regardless of my umask.
So they are zipped with default Windows perms (Windows lacks a umask analogue to change these) then unzipped on the players computer, preserving those perms (with zip ignoring the perms of the players machine, man zip shows no provision to use the local umask).
So this is working correctly (it's correct behavior of using zip on Windows and unzip on the players machine) and it isn't breaking KSP in any way.
I'm sorry but I don't see how this is a bug, it's certainly not a bug in KSP, this would have been better as feedback.
Reclassifying.
#4
Updated by psycho_zs about 9 years ago
Well, this is obviously not a bug in KSP, but an issue of distribution.
Re-summarizing:
Site's download section gives impression of OS-specific downloads, but in reality it is the same archive. Unpacking that archive on Linux results in exec bits being set on files that aren't executables and group write permissions set on the whole unpacked distribution. Both are "just not right" by Linux standards (forget umask :) ).
A script to quickly fix permissions:
#!/bin/bash
# Place script in KSP dir and execute.
# Do not execute if placed anywhere else!
# Change dir to location of self
cd "$(dirname "$(readlink -f "$0")")"
# set 755 for all directories
find . -type d -exec chmod 755 "{}" \;
# set 644 for all files
find . -type f -exec chmod 644 "{}" \;
# set exec for executables
chmod +x KSP.x86 KSP.x86_64 Launcher.x86 Launcher.x86_64
#5
Updated by sal_vager about 9 years ago
Not everyone is tech savvy though, despite using Linux, many KSP players on Linux are only using it because of the 64bit binary, asking them to also run a post install script for something they may not understand maybe asking too much, especially if KSP works fine without it.
And yes it may not be "right" by Linux/Unix standards but it is right according to how zip functions, zip preserves the files permissions, and on Windows these are permissive.
#6
Updated by TriggerAu over 8 years ago
Updated by - Status changed from New to Needs Clarification
#7
Updated by Corax over 5 years ago
Updated by sal_vager wrote:
Not everyone is tech savvy though, despite using Linux, many KSP players on Linux are only using it because of the 64bit binary, asking them to also run a post install script for something they may not understand maybe asking too much, especially if KSP works fine without it.
And yes it may not be "right" by Linux/Unix standards but it is right according to how zip functions, zip preserves the files permissions, and on Windows these are permissive.
Came here to finally report this exact same issue that has been bugging me for years.
It's not about being "right by any standards", but about closing an avoidable security hole.
That argument of "not asking too much of poor tech-illiterate Linux newbies" to run a shell script may have been a valid stance, however weak, when this issue was first reported, but now we have not one but two DLCs that require the user to do exactly that.
How about instead of asking all two of the not so tech savvy Linux users – ask the developers to run a script on their end, once, before packaging the archive for distribution?! We may even find a tech savvy Linux user to write that script for them in PowerShell or .Net or whatever Windows is using these days, if they are not tech savvy enough for that.