* Christian Brauner:
quoted
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?
quoted
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
On Mon, Mar 02, 2020 at 01:09:06PM +0100, Florian Weimer wrote:
* Christian Brauner:
quoted
quoted
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?
You can currently do RESOLVE_NO_SYMLINKS | O_NOFOLLOW. So I'd expect
RESOLVE_SYMLINKS | O_NOFOLLOW would work as well. But from what it looks
like having no symlink resolution be opt-in seems more likely.
quoted
quoted
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.
Ok, maybe then we'll just leave RESOLVE_NO_SYMLINKS as opt-in.
On Mon, Mar 02, 2020 at 01:20:00PM +0100, Christian Brauner wrote:
On Mon, Mar 02, 2020 at 01:09:06PM +0100, Florian Weimer wrote:
quoted
* Christian Brauner:
quoted
quoted
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?
You can currently do RESOLVE_NO_SYMLINKS | O_NOFOLLOW. So I'd expect
RESOLVE_SYMLINKS | O_NOFOLLOW would work as well. But from what it looks
like having no symlink resolution be opt-in seems more likely.
One difference to openat() is that openat2() doesn't silently ignore
unknown flags. But I'm not sure that would matter for iplementing
openat() via openat2() since there are no flags that openat() knows about
that openat2() doesn't know about afaict. So the only risks would be
programs that accidently have a bit set that isn't used yet. But that
seems unlikely. And I'm not aware of any flag that was deprecated that
some programs could still pass (a problem we had with CLONE_DETACHED for
example).