And the inode_permission() check is wrong, but at least it does have
the important check there (ie that FMODE_WRITE one). So doing the
inode_permissions() check at worst just makes it fail too often, but
since it's all a "optimistically dedupe" anyway, that kind of "fail in
odd situations" doesn't really matter.
So for allow_file_dedupe(), I'd suggest:
(a) remove the inode_permission() check in allow_file_dedupe()
(b) remove the uid_eq() check for the same reason (if you didn't open
the destination for write, you have no business deduping anything,
even if you're the owner)
So we're going to break userspace?
https://github.com/markfasheh/duperemove/issues/129
I am actually not sure why writability is needed for 'dest' at all. Of
course, the deduplication might cause a write on the block device or
underlying storage, but from the abstract fs perspective, neither the
data nor any metadata can change, regardless of the success of the
deduplication. The only attribute that might change is the position of
the block on the blockdevice. Does changing this information require
write permissions?
If I interpret the linked issue correctly, only needing read permissions
on both fds would also solve this problem.
Best regards,
Ansgar
--
M.Sc. Ansgar Lößer
Fachgebiet Kommunikationsnetze
Fachbereich für Elektrotechnik und Informationstechnik
Technische Universität Darmstadt
Rundeturmstraße 10
64283 Darmstadt
E-Mail: ansgar.loesser@xxxxxxxxxxxxxxxxxxx
http://www.kom.tu-darmstadt.de
