Messages in this thread | | | Subject | Re: Suggested new user link command | From | Tony Wallace <> | Date | Wed, 2 May 2018 00:17:13 +1200 |
| |
Two issues here: 1) Use case (which I have) 2) Permissions
1) Use case
I am trying to build a backup system. To avoid duplication of files over multiple backups I take an Md5 check sum of file contents. Files with the same sum are hardlinked together. Files are linked in to a standard directory structure a new link for each backup that the file is part of. When all backups pointing to a file are deleted the reference count drops to zero and the file is deleted. We can keep a database of checksums and there related inode numbers for linking purposes. So why not have some reference copy to link against it would take no extra space. Well it doesn't, but it keeps at least one copy of the file on disk forever and the reference count never drops to zero. Using one of the backup copies to link to (as stored as the reference copy in the database) will not work as it could be deleted at any time.
I have seen on stack overflow others wanting to do this also.
2) Permissions
To maintain security there are two requirements: 2.1) The effective user must have rights to the inode, that is they must either own it or be root 2.2) The effective user must have rights file creation rights to the directory where it is being linked
If you say no, that is fine, but I do think this idea has merit and can be done without compromising the system.
I am off to bed, it is the middle of the night here in New Zealand.
Tony
On 01/05/18 23:04, Richard Weinberger wrote: > On Tue, May 1, 2018 at 12:58 PM, Tony Wallace <tony@tony.gen.nz> wrote: >> Good point. But there are gid and uid fields in inode disc record. >> >> https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Inode_Table >> >> I assume these can be use to ensure that the directory in which it is to >> be placed has permissions to accept the inode. If that is not the case >> then it would have to be a root only syscall. > Before we dig into details, please come up with a very good use case. :-) > But I'm with Bernd, I don't think it is worth the permissions hassle. >
| |