lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <388f79ad-4ed0-ec39-f649-5c120ee9dc2f@tony.gen.nz>
Date:   Wed, 2 May 2018 00:17:13 +1200
From:   Tony Wallace <tony@...y.gen.nz>
To:     Richard Weinberger <richard.weinberger@...il.com>
Cc:     Bernd Petrovitsch <bernd@...rovitsch.priv.at>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: Suggested new user link command

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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ