Hi, Adam Goryachev wrote on 2008-12-20 00:55:45 +1100 [Re: [BackupPC-users] Permission denied during backup]: > [...] > BTW, not likely relevant in this specific case, but root can't access > all files... damn, in trying to prove this to myself, I noticed it > didn't work. However, I seem to recall that it was possible to deny root > access to files by making the either owner/group root, and then setting > permissions for owner/group to 0.
this is generally not correct. For root (CAP_DAC_OVERRIDE, to be exact) the permission bits for read/write access are *not* checked (well, a failure is overridden, to be exact) and execute is allowed if *any* x-bit is set. It is possible to remove CAP_DAC_OVERRIDE from root's capabilities (with grsecurity and almost certainly selinux too, but I haven't checked) as well as possibly grant the capability to other users (though I haven't checked that either, it's just how I understand it). This means you can *make* what you say true (by removing root's CAP_DAC_OVERRIDE) as well as possibly create a backup user which has CAP_DAC_OVERRIDE (CAP_DAC_READ_SEARCH, ...) but none of the other special capabilities (would be an interesting topic - does anyone know more about this?). If you are mounting a file system via NFS, some checks are done on the server, which has an option (root_squash) to map root to nobody. This means the NFS *server* can enforce giving root (on the *client*) less access than permissions would suggest (owner root, permissions rwx, yet no access because the check is done for 'nobody', not 'root'). > can anyone confirm if this was only valid in older versions of linux, or > suggest cases where it is valid? I don't think it was ever possible to block root access by restrictive owner or group permissions, but I'm not sure. I might have a 0.95c kernel somewhere, but I somehow doubt it would handle my SATA disks ;-). > BTW, this case is valid, and can work to deny access to a normal user.. True. As I said, without CAP_DAC_OVERRIDE, it would work for root too. Johan Ehnberg wrote on 2008-12-19 16:29:10 +0200 [Re: [BackupPC-users] Permission denied during backup]: > [...] > You are right about root not being perfectly omnipotent. Here's one > quite different case which I see in my logs all the time: > > Remote[1]: rsync: readlink "/home/johan/.gvfs" failed: Permission denied > (13) /home/johan is on NFS, right? > 'ls -la' gives (note the size!) > dr-x------ 2 johan johan 0 2008-12-19 14:39 .gvfs Strange. Even an empty directory needs to contain '.' and '..' entries (and the link count 2 suggests that it does). How any file system would store that in 0 bytes ... maybe in the inode? Mis-information from the NFS server? What FS type is this (on the server)? > 'sudo ls -la' gives > d????????? ? ? ? ? ? .gvfs I can't remember having seen that kind of 'ls' output, but a failure to stat() /home/johan/.gvfs has more to do with the permissions on /home/johan than the subdirectory. The results you get from mismatched 'r' and 'x' permissions on directories tend to be confusing (being able to read a directory but not access (and thus stat()) the files in it, or being able to access the files but not read the directory). > In my setup, there are no other files on a "normal" system that will not > be backed up (when sane sane excludes are used). "Sane excludes" being such that match everything that cannot be backed up? :) Regards, Holger ------------------------------------------------------------------------------ _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/