linux-kernel - Re: Suggested new user link command

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: <a91ef2fb-09ed-51ae-5dfa-8f71ec81f20c@tony.gen.nz>
Date:   Tue, 1 May 2018 22:58:33 +1200
From:   Tony Wallace <tony@...y.gen.nz>
To:     Bernd Petrovitsch <bernd@...rovitsch.priv.at>,
        linux-kernel@...r.kernel.org
Subject: Re: Suggested new user link command

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.


Tony


On 01/05/18 21:03, Bernd Petrovitsch wrote:
> Hi 
>
> On Tue, 2018-05-01 at 20:03 +1200, Tony Wallace wrote:
>> I am suggesting a new command for linking files.  Currently there is
>> no
>> easy way to link a file with a known inode number to its correct
>> position in the directory tree.  
>>
>>
>> int ilink(const int inode, const char *newpath)
> ... avoiding any permission checks on all paths to the existing names.
>
>> The current alternative to this command is to find the file path
>> associated with an inode using the find command and then once found
>> using a standard link command.  Obviously this is very inefficient.  
> That's the price for security as it requires proper permissions.
> Or is this a root-only syscall?
>
> MfG,
> 	Bernd