Re: Suggested new user link command

From: Tony Wallace <tony@tony.gen.nz>
To: Richard Weinberger <richard.weinberger@gmail.com>
Cc: Bernd Petrovitsch <bernd@petrovitsch.priv.at>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Suggested new user link command
Date: Wed, 2 May 2018 00:17:13 +1200	[thread overview]
Message-ID: <388f79ad-4ed0-ec39-f649-5c120ee9dc2f@tony.gen.nz> (raw)
In-Reply-To: <CAFLxGvxpe78WhrEKcKRt5XRBMtT-mZUe9Bm=sQsn8-f1TnX0eQ@mail.gmail.com>

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.
>