all permission and ownerships on /var have been changed.
Hello dear community ,
An application manager tried to fix a small issue on a server, but created a major issue by setting all permissions to 777 on /var and the included directories and files.
I guess he ran chmod -R 777 /var.
It is not totally clear what he did with the ownerships.
I would like to know if some know a way to copy the permission and ownership structure from a server with the same directory/file hierarchy.
Kind regards,
Jan Gerrit
Responses
Jan,
One idea is to build a script (python, perl etc) that harvests the permissions from a known good like system, perhaps even takes the read permissions and converts it to octal with the path and directory/file and then build a script to make the change. (this may not be optimal)
Another alternative, do you have a recent backup of the /var directory structure? You could restore it at a different location on the same system and then do "find /path/to/restored/var" grab the results and then take the result into a file, and use a combination of sed to build a chmod script for both the source and the target end of the chmod and use "chmod--reference $from $target" which would require a bit of creativity, but certainly could be done. The "--reference" reads the permission of the source ($from variable I used above) and applies it to the target (which also works in chcon, chown as well).
I'm confident there are more elegant ways than that, but those are a couple of immediate options.
First, create a permissions - attribute dump using "getfacl -R /var > /tmp/var-attributes.ac" from a similar node with right attributes as defined for /var & now, move this file to the corrupted system where /var attributes are mixed-up, and finally restore using the command "setfacl --restore /tmp/var-attributes.ac".. I see this is working as expected for me (assuming acl enabled)..
Yes, agree with "R. Hinton " there could be multiple ways as he suggested..
For files that are managed via RPM, you can always script out something using the --setperms option. You could start with something like:
rpm --setperms $(rpm -qf $(find /var -type f -o -type d) --qf '%{name}\n' | grep -v 'is not owned' | sort -u)
Granted, the above assumes that you didn't have any reason to change the permissions on RPM-owned files and directories and ignores files/directories that aren't RPM managed. Primary value is returning what you can return to vendor-standard values.
While you can use a "like" box as a reference from which to create a permission-restore template, finding a valid template to copy from can be a challenge: if you're not deploying scale-out architectures, you likely don't have many "identical" boxes to use as templates ...and if you are using scale-out architectures, "why bother to fix when you can just replace".
As to "restore from tape": it may not be 100% necessary to do that. Depending on how your backup system stores things, you could always read metadata from the tape to establish your proper ownerships and permissions but otherwise not restore. Similarly, if you can't read just the metadata, you could always to an alternate-location restore, then use that restore location's contents as your template.
I like Tom's approach, and Murthy brought up a good point too. As I have thought of this - one system's file set may not fully represent the target system with the issue. So it may be good to validate and even consider a combination of checks/methods - including the posts everyone's made above. Hopefully there's nothing someone built from source and is not under rpm control. Afterwards, a recursive check of permissions for validation might be good.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
