On 13.08.2013 13:17, Paul Slootman wrote: > On Tue 13 Aug 2013, Matthias Schniedermeyer wrote: > > > That aside that's not what i meant. > > That's the problem with one-word answers, people have to guess what you > mean. > > > > Hardlinking a file doesn't change it's owner/group/permission > > (All Hardlinks have the same user/group/permissions). > > I never said that.
You implied that by your assertion that you suddenly can read a file after hardlinking it. > I said that if a hardlink can be made (and I meant on a modern linux > kernel, with default settings) then the user already has permissions to > do anything with the file. I forgot already about the old semantics :) Did you read what i just wrote? You can't do anything more to the file than before you hardlinked it. (Except rename the hardlink, but that's because you have permission to the directory and not the file itself. That is also the reason why you can delete the hardlink (But not the original file)) So if you can read the shadow-file after you hardlink it, you are able to read the original file. If you can read the file after backup/restore (Case the OP described), then the vulnerability isn't the hardlink itself it's the backup/restore that didn't store/restored the correct owner/group/permissions. The backup could even "rewind" the shadow-file, if it overwrites the file instead of creating a temporary file and renameing it. With rsync '--inplace' you could rewind any file which hardlinks to something else, when restored. -- 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
