Re: Suggested new user link command
From: Tony Wallace
Date: Tue May 01 2018 - 08:17:33 EST
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@xxxxxxxxxxx> 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.
>