On 13.08.2013 15:51, Paul Slootman wrote: > On Tue 13 Aug 2013, Matthias Schniedermeyer wrote: > > > > I read your sentence differently: > > > > > If he can make a HARD link to the shadow file, then he can already > > > read it - and worse. > > > > My understanding of your sentence says: > > The ability to hardlink, means that anyone can read any file they can > > make a hardlink to. > > Then I didn't express myself clearly enough. Again, keep in mind I was > thinking from the perspective of a linux 3.6 and up kernel without any > sys tweaks.
3.6 is NO different. For "least surprise" reasons with protected_hardlinks you can't create hardlinks to file you can't access. Nothing more. But that doesn't preclude: - Existing hardlinks - Someone with permission (e.g. root) to make a hardlink for you. > > Having access to the directory entry is not the same as having access to > > the inode. User/group/permission is on the inode NOT the > > directory-entry. > > I have access to the inode when I do an "ls -l" of the file :-P No, you access to the directory entry, which contains a pointer to the inode. But i wasn't describing what i meant clearly. What i actually meant is: Accesses to the "bytestream" pointed to by the inode (which in turn is pointed to by the directory entry) Directory entry -> inode -> bytestream > perhaps you mean "modification permissions". I think you mean "inode change modification". IOW permission to change the permission settings of a inode. 'man 2 chmod' says for who can change the permissions (manpages Version 3.52): - snip - The effective UID of the calling process must match the owner of the file, or the process must be privileged ... . - snip - > Then again, when hardlinking, I'm changing the link count which is > stored in the inode... :) True, but it's not something you do directly, it's a side-effect of the operation you told the kernel to execute. IOW the link-count is an implicitly handled implementation detail. > I'm done here... coming back to the OP's problem: if the backup is made > by root, then a user should not be allowed to access all parts of that > backup. The security problem is there, and not in rsync. Ack. -- Matthias -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
