linux-kernel - [RFC][6/11][MANUX] Kernel compatibility : directory hardlinks

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-next>] [day] [month] [year] [list]

Message-ID: <534D3765.4090403@manux.info>
Date:	Tue, 15 Apr 2014 15:43:01 +0200
From:	Emmanuel Colbus <ecolbus@...ux.info>
To:	linux-kernel@...r.kernel.org
Subject: [RFC][6/11][MANUX] Kernel compatibility : directory hardlinks

Now for something that has to do both with syscalls and filesystems...

My operating system relies heavily upon hardlinks, and, amongst others,
directory hardlinks. (Yes, that's what my ext2l partitions are for. Not
only, but this is part of it).

To allow distinguishing them from true directories, I've introduced a
value S_IFDHL equal to 0130000, both for the file mode in stat(2) and
for the type_entry field in the dirent structure, in getdents64(2).
(However, it's not visible to normal applications, because seeing this
value in getdents() requires asking for it with a new syscall and having
the privileges to do so, while seeing the value in stat(2) is impossible
for them because their call gets routed towards the target directory -
my directory hardlinks are implemented somewhat like symlinks, but with
inode numbers. Thus, the userspace requires no modifications).

Is this value acceptable? And, if it is, could you mark it as reserved
(or otherwise avoid reusing it), so that there's no collision with it in
the future?

Thank you,

Emmanuel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/