GNOME Bugzilla – Bug 608825
(sabayon) Implement permissions handling
Last modified: 2010-02-22 17:56:21 UTC
sabayon-2.29.5 Sabayon must learn how to track permissions of files that it is to apply. * Specify a metadata format to include within the .zip file to know the permissions to set when unpacking files from the Sabayon profile archive. * If /sbin/restorecon exists, restorecon in order to ensure labels are correct. Hard part: What should the metadata format be?
Any thoughts as to what other than drwxrwxrwx permission bits should be included in the metadata? Given there exists no written specification proposal I am just going to implement a simple Proof of Concept based on the following assumptions. * Application happens as the non-root user * Owner/group is irrelevant * restorecon alone will DTRT to set desired SELinux contexts, so we don't need to store that in the metadata. * If these assumptions are true, then it would be sufficient for the metadata file to contain permission bits and filename, one line per file. Proposed changes: * Editor dialog has a column showing the permissions. Saving saves permissions and filenames into sabayon-permissions.txt. * Details view displays a permissions column for each file. * sabayon-apply sets permissions on directories/files based upon sabayon-permissions.txt. Sample sabayon-permissions.txt: drwxr-xr-x. Desktop -rw-r--r--. Desktop/Lesson 27.odt drwx------. .ssh -rw-r--r--. .ssh/known_hosts Any thoughts?
6177e57814254f3131fdfe4df1ebc8dfcf66f90a Record st_mode file permissions in metadata. 74ff677211263e74b0ed0125fc55cabc706bfba1 Read st_mode from metadata and apply to files or directories during extract() Remaining problems: * If you save a file, then subsequently change the permissions of that file without changing the contents of the file, the change watcher doesn't see it as a change. * Not sure what happens if you read metadata that is lacking st_mode. I might need to add some conditionals for this. Will look into this tomorrow.
(In reply to comment #2) > * Not sure what happens if you read metadata that is lacking st_mode. I might > need to add some conditionals for this. Will look into this tomorrow. commit dea42facd30f1b326224fdaf672f1dfe0202eeda Author: Warren Togami <wtogami@redhat.com> Date: Thu Feb 18 13:38:55 2010 -0500 Gracefully ignore st_mode if the metadata node is missing that particular prop. Another problem I need to solve: * If you have a .desktop file in /etc/skel/Desktop, it fails to restore the permissions of that file. For example, 755 is necessary for GNOME to allow it to be a "Trusted" launcher, but it is currently being restored as 644.
Another problem: * If you have a file and symlink pointing to it, upon apply the file is gone while symlink is restored. This is a serious issue that I need to solve first.
(In reply to comment #4) > Another problem: > * If you have a file and symlink pointing to it, upon apply the file is gone > while symlink is restored. This is a serious issue that I need to solve first. This was solved in Bug #610488. The .desktop file permission restoration problem in Comment #3 remains.
Filed the remaining corner cases as separate bugs, closing this bug. Bug #610712 - (sabayon) Permissions of restored .desktop file incorrect Bug #610713 - (sabayon) Permission change not detected as change