linux-kernel - Re: Have RESOLVE_* flags superseded AT

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: <8736arnel9.fsf@oldenburg2.str.redhat.com>
Date:   Mon, 02 Mar 2020 13:09:06 +0100
From:   Florian Weimer <fweimer@...hat.com>
To:     Christian Brauner <christian.brauner@...ntu.com>
Cc:     David Howells <dhowells@...hat.com>, linux-api@...r.kernel.org,
        viro@...iv.linux.org.uk, metze@...ba.org,
        torvalds@...ux-foundation.org, cyphar@...har.com,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Have RESOLVE_* flags superseded AT_* flags for new syscalls?

* Christian Brauner:

>> But that's inconsistent with the rest of the system.  And for example,
>> if you make /etc/resolv.conf a symbolic link, a program which uses a new
>> I/O library (with the new interfaces) will not be able to read it.
>
> Fair, but I expect that e.g. a C library would simply implement openat()
> on top of openat2() if the latter is available and thus could simply
> pass RESOLVE_SYMLINKS so any new I/O library not making use of the
> syscall directly would simply get the old behavior. For anyone using the
> syscall directly they need to know about its exact semantics anyway. But
> again, maybe just having it opt-in is fine.

I'm more worried about fancy new libraries which go directly to the new
system calls, but set the wrong defaults for a general-purpose open
operation.

Can we pass RESOLVE_SYMLINKS with O_NOFLLOW, so that we can easily
implement open/openat for architectures that provide only the openat2
system call?

>> AT_SYMLINK_NOFOLLOW only applies to the last pathname component anyway,
>> so it's relatively little protection.
>
> So this is partially why I think it's at least worth considerings: the
> new RESOLVE_NO_SYMLINKS flag does block all symlink resolution, not just
> for the last component in contrast to AT_SYMLINK_NOFOLLOW. This is
> 278121417a72d87fb29dd8c48801f80821e8f75a

RESOLVE_NO_SYMLINKS shouldn't be the default, though (whoever is
responsible for applying that default).  Otherwise system administrators
can no longer move around data between different file systems and set
symbolic links accordingly.

Thanks,
Florian