Somebody in the thread at some point said: > Andy Green wrote: > >> If you can't see the pam config or resolv.conf on an unknown box you >> don't know what will work either until you start trying and look. > > Those don't have much to do with file access control. You can probably figure out a canonical list of who can touch what from the rules somehow if you really want it. >> Permissive was useful for me to gingerly add selinux to a remote box >> that never had it before, the box couldn't be killed but I could learn >> where the issues were (a handful, FWIW). I turned it straight to >> enforcing and rebooted and fixed them up. >> >> The one golden rule I found seems to be to do with avoiding mv and using >> cp when introducing files to a new selinux directory tree. So if you >> created files in ~ and mv them to /var/www/html, because it is done by >> shifting inodes around and not creating files, they will retain the home >> directory related selinux label and make trouble. If you cp'd them >> over, new files are created in the new directory context, they will have >> httpd-related labels. > > Does that mean some backup/restore methods work and some don't? My > preference for almost all copy/move operations is rsync because it is > pretty much the same regardless of whether the source/dest are local or > not. Will it work in the case where both are local? What happens when > they aren't? If your copying app isn't selinux-aware (tar is, for example: it can store and regenerate the labels after the files are created), then the key point is, is the new file "created" in the new directory? If so, no matter how, then it will get a label based on the directory hierarchy it was created in, and that is usually "the right thing". rsync is definitely creating files in situ so it will normally not cause trouble. Doesn't matter if the source is local or remote, the label is decided at file creation time at the destination. -Andy
