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 AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
