Quick Links
Summary
Linux file permissions control who can do what with files and directories.
But if they get messed up, restoring them can be a nightmare.
Cloning a working files permissions is the fastest solution.
The Mess and Stress of Bad Permissions
On Linux, files and directories have a set ofpermissions.
They control which actions can be performed, and by whom.
Permissions either allow or deny someone reading from a file, writing to it, or executing it.
For a file, executing means running a script or program.
For a directory, execute means changing into that directory withthe cd command.
Permissions directly affect the proper operation and security of your gear.
Badly set permissions can cause havoc, effectively putting your data out of your reach.
A file or directory has three sets of permissions.
you’re able to get into a similar situation if you make mistakes with thechownandchmodcommands.
The chmod command sets file permissions, and the chown command sets file ownership.
Hand-fixing these types of error conditions is tedious.
The answer is to use chown and chmod to clone the controls of a correctly configured file.
The Problem?
I needed some files from an archive file Id been sent.
Iunpacked the archive, but the extracted directory had a padlock badge on its icon.
I had to provide the root password to enter the directory.
Double-clicking on its own wasnt enough.
Checking with ls (again, using sudo) reveals the problem.
The root user owns the directory, and nobody has read or write permissions.
Lets sort out the ownership issues first.
Cloning Ownership With chown
I want to set the ownership of the file to me.
My username is dave.
Well use the chown command, and copy the ownership prefs from a directory that is set correctly.
The–referenceoption tells chown which directory to copy the permission parameters from.
We can check with ls that user dave is now the owner of the files and directories.
We still need to use sudo because we havent sorted out the permissions yet.
Now that weve reclaimed ownership of the files and directories, we can fix the permissions.
Setting the ownership is easy.
All the files and directories are owned by the same user, so they all receive the same tweaks.
But directories and executable files must have the x (execute) permission set for them.
Regular files dont need that permissions set.
So we need to create several sets of permissions and apply them to the appropriate files.
We can do this in three steps.
Well use a regular file as the reference file first.
This will set the permissions as though everything is a regular file.
Then well use a referenceexecutablefile to set the permissions for any shell scripts.
Finally, well use chmod in the traditional way to set the execute permission for the directories.
We need to restore the execute permission on any scripts.
Weve got a reference script we can take the permissions from.
We can see that the execute permission has been set on the “appveyor.sh” file.
Restoring the execute permission on the directories involves a neat trick.
We cant use a wildcard because its liable to match files too.
So what we do is use theuppercaseX permission flag.
We can use this because our executable scripts already have the executable bit set, and theyll retain it.
All the directories in the directory tree will have the executable bit set, too.
We can see the ACL options on the existing file using the getfacl command.
The owner, dave has read, write, and execute permissions.
User mary has read and write permissions.
To clone these options to the files in the project directory, we use the setfacl command.
The files we want to apply the ACL tweaks to are in a directory called source.
The–set-fileoption usually takes the name of a file that you want to copy the settingsfrom.
Using a single hyphen - as the filename tells setfacl to use stdin as its data source.
This will be our piped data.
Looking at any of the files in the source directory verifies that the copied ACL controls have been applied.