the slave */
+#define TIOCGPTPEER_IO('T', 0x41) /* Safely open the slave */
This is a user API change. When was the ioctl added?
It was just pulled this merge window (4.13-rc1).
% git tag --contains 54ebbfb1603415d9953c150535850d30609ef077
%
--
Aleksa Sarai
Software Engineer (Containers)
SUSE
This ioctl does nothing to justify an _IOC_READ or _IOC_WRITE flag
because it doesn't copy anything from/to userspace to access the
argument.
Acked-by: Aleksa Sarai <asa...@suse.de>
Oops, I misunderstood what _IOR means semantically. TIL -- thanks!
--
Aleksa Sarai
Software En
an Brauner <christian.brau...@ubuntu.com>
Cc: Valentin Rothberg <vrothb...@suse.com>
Signed-off-by: Aleksa Sarai <asa...@suse.de>
Is this going to be documented anywhere? Is there a man page update
that also goes along with this?
I will add one, I didn't know where the man-pag
an Brauner <christian.brau...@ubuntu.com>
Cc: Valentin Rothberg <vrothb...@suse.com>
Signed-off-by: Aleksa Sarai <asa...@suse.de>
Is this going to be documented anywhere? Is there a man page update
that also goes along with this?
I will add one, I didn't know where the man-page
an Brauner <christian.brau...@ubuntu.com>
Cc: Valentin Rothberg <vrothb...@suse.com>
Signed-off-by: Aleksa Sarai <asa...@suse.de>
---
arch/alpha/include/uapi/asm/ioctls.h | 1 +
arch/mips/include/uapi/asm/ioctls.h| 1 +
arch/parisc/include/uapi/asm/ioctls.h | 1 +
arch/power
can move it if the hex order is
more important for maintainence.
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
Changes in v2:
* Reordered addition to ioctls.h to follow correct hex ordering.
Aleksa Sarai (1):
tty: add TIOCGPTPEER ioctl
arch/alpha/include/uapi/asm/ioctls.h | 1 +
arch/mips/include/uapi/asm/ioctls.h| 1 +
arch/parisc/include/uapi/asm/ioctls.h | 1 +
arch/powerpc/include
an Brauner <christian.brau...@ubuntu.com>
Cc: Valentin Rothberg <vrothb...@suse.com>
Signed-off-by: Aleksa Sarai <asa...@suse.de>
---
arch/alpha/include/uapi/asm/ioctls.h | 1 +
arch/mips/include/uapi/asm/ioctls.h| 1 +
arch/parisc/include/uapi/asm/ioctls.h | 1 +
arch/power
an Brauner <christian.brau...@ubuntu.com>
Cc: Valentin Rothberg <vrothb...@suse.com>
Signed-off-by: Aleksa Sarai <asa...@suse.de>
---
arch/alpha/include/uapi/asm/ioctls.h | 1 +
arch/mips/include/uapi/asm/ioctls.h| 1 +
arch/parisc/include/uapi/asm/ioctls.h | 1 +
arch/power
-declaration \
-Wno-format-security \
+ -Wno-error=int-in-bool-context \
-std=gnu89 $(call cc-option,-fno-PIE)
Ah sorry, I committed that by accident. I'll send a fixed version.
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https
Changes in v3:
* Defined a compat_ioctl callback for all pty ioctls, since they are
all 32-bit and 64-bit compatible.
* Made TIOCGPTPEER support 32-bit userspace.
Aleksa Sarai (2):
tty: add compat_ioctl callbacks
tty: add TIOCGPTPEER ioctl
Makefile | 1
.
Signed-off-by: Aleksa Sarai <asa...@suse.de>
---
Makefile | 1 +
drivers/tty/pty.c | 22 ++
fs/compat_ioctl.c | 6 --
3 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index 470bd4d9513a..fb689286d83a 100644
--- a/Makefile
.
Signed-off-by: Aleksa Sarai <asa...@suse.de>
---
drivers/tty/pty.c | 22 ++
fs/compat_ioctl.c | 6 --
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index 65799575c666..2a6bd9ae3f8b 100644
--- a/drivers/tty/pty.c
an Brauner <christian.brau...@ubuntu.com>
Cc: Valentin Rothberg <vrothb...@suse.com>
Signed-off-by: Aleksa Sarai <asa...@suse.de>
---
arch/alpha/include/uapi/asm/ioctls.h | 1 +
arch/mips/include/uapi/asm/ioctls.h| 1 +
arch/parisc/include/uapi/asm/ioctls.h | 1 +
arch/power
Changes in v4:
* Dropped an accidental change to Makefile.
Aleksa Sarai (2):
tty: add compat_ioctl callbacks
tty: add TIOCGPTPEER ioctl
arch/alpha/include/uapi/asm/ioctls.h | 1 +
arch/mips/include/uapi/asm/ioctls.h| 1 +
arch/parisc/include/uapi/asm/ioctls.h | 1 +
arch/powerpc
,
unsigned int cmd, unsigned long arg);
If you like, I can change (*ioctl) to return longs as well, and then
change all of the call-sites (since unlocked_ioctl also returns long).
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
that restrict actions.
Not to mention that the O_* flags have silly values which we shouldn't
replicate in new syscalls IMHO.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
st do
>
> pid = fork();
> pidfd_open(pid);
While the race window would be exceptionally short, there is the
possibility that the child will die and their pid will be recycled
before you do pidfd_open(). CLONE_PIDFD removes the race completely.
--
Aleksa Sarai
Senior Software Engineer
On 2019-05-16, Oleg Nesterov wrote:
> On 05/17, Aleksa Sarai wrote:
> > On 2019-05-16, Oleg Nesterov wrote:
> > > On 05/16, Christian Brauner wrote:
> > > > With the introduction of pidfds through CLONE_PIDFD it is possible to
> > > > created pidfds at p
the shortcut might -1 be better?
I'd suggest not using negative numbers, and instead reserving them for
PIDTYPE_TGID if we ever want to have that in the future. IMHO, doing
pfd = pidfd_open(getpid(), 0);
is not the end of the world.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
On 2019-07-12, Al Viro wrote:
> On Sun, Jul 07, 2019 at 12:57:32AM +1000, Aleksa Sarai wrote:
> > @@ -1442,8 +1464,11 @@ static int follow_dotdot_rcu(struct nameidata *nd)
> > struct inode *inode = nd->inode;
> >
> > while (1) {
> > -
On 2019-07-12, Al Viro wrote:
> On Sun, Jul 07, 2019 at 12:57:27AM +1000, Aleksa Sarai wrote:
> > Patch changelog:
> > v9:
> > * Replace resolveat(2) with openat2(2). [Linus]
> > * Output a warning to dmesg if may_open_magiclink() is violated.
> > *
On 2019-07-12, Aleksa Sarai wrote:
> On 2019-07-12, Al Viro wrote:
> > On Sun, Jul 07, 2019 at 12:57:31AM +1000, Aleksa Sarai wrote:
> > > Previously, path_init's handling of *at(dfd, ...) was only done once,
> > > but with LOOKUP_BENEATH (and LOOKUP_IN_ROOT) we have
On 2019-07-12, Al Viro wrote:
> On Sun, Jul 07, 2019 at 12:57:31AM +1000, Aleksa Sarai wrote:
> > Previously, path_init's handling of *at(dfd, ...) was only done once,
> > but with LOOKUP_BENEATH (and LOOKUP_IN_ROOT) we have to parse the
> > initial nd->path at differen
On 2019-07-12, Al Viro wrote:
> On Sun, Jul 07, 2019 at 12:57:28AM +1000, Aleksa Sarai wrote:
> > @@ -514,7 +516,14 @@ static void set_nameidata(struct nameidata *p, int
> > dfd, struct filename *name)
> > p->stack = p->internal;
> > p->dfd = df
On 2019-07-12, Al Viro wrote:
> On Fri, Jul 12, 2019 at 01:55:52PM +0100, Al Viro wrote:
> > On Fri, Jul 12, 2019 at 01:39:24PM +0100, Al Viro wrote:
> > > On Fri, Jul 12, 2019 at 08:57:45PM +1000, Aleksa Sarai wrote:
> > >
> > > > > > @@ -2350,9 +2
On 2019-07-12, Al Viro wrote:
> On Fri, Jul 12, 2019 at 10:20:17PM +1000, Aleksa Sarai wrote:
> > On 2019-07-12, Al Viro wrote:
> > > On Sun, Jul 07, 2019 at 12:57:28AM +1000, Aleksa Sarai wrote:
> > > > @@ -514,7 +516,14 @@ static void set_nameidata(struct nameidat
being done during
resolution, and we aren't definitely doing them all in
handle_dots(). So I assumed re-taking it could result in me
breaking RCU-walk which obviously would be bad. Since I am the only
thing using nd->r_seq, I can re-take it without issue.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
On 2019-07-08, Michael Ellerman wrote:
> Aleksa Sarai writes:
> > diff --git a/tools/testing/selftests/openat2/Makefile
> > b/tools/testing/selftests/openat2/Makefile
> > new file mode 100644
> > index ..8235a49928f6
> > --- /dev/null
> >
for
writing (because it is the current->mm of a live process).
With the new O_PATH restrictions, changing the default mode of these
magic-links allows us to avoid delayed-access attacks such as we saw in
CVE-2019-5736.
Signed-off-by: Aleksa Sarai
---
fs/proc/base.c |
rror and do not
cause any user-visible problems. In order to give users a heads-up, a
warning is output to dmesg whenever may_open_magiclink() refuses access.
[1]: http://git.altlinux.org/people/legion/packages/kbd.git
Suggested-by: Andy Lutomirski
Suggested-by: Christian Brauner
Signed-off-by: Al
stworthiness to this
construction.
[*] It may be acceptable in the future to do a path_is_under() check
after resolving a magic-link and permit resolution if the
nd_jump_link() result is still within the dirfd. However this seems
unlikely to be a feature that people *really* need* -- i
ase path
seems to be the most consistent behaviour (and also avoids foot-gunning
users who want to scope paths that are absolute).
[1]: https://github.com/cyphar/filepath-securejoin
Suggested-by: Christian Brauner
Signed-off-by: Aleksa Sarai
---
fs/namei.c| 41
619151/
[3]: https://lwn.net/Articles/603929/
[4]: https://lwn.net/Articles/723057/
Cc: Christian Brauner
Suggested-by: David Drysdale
Suggested-by: Al Viro
Suggested-by: Andy Lutomirski
Suggested-by: Linus Torvalds
Signed-off-by: Aleksa Sarai
---
fs/namei.c| 85 ++
he
expense of further complicating O_PATH makes little sense. Ultimately,
if users ask for this we can always add RESOLVE_EMPTY_PATH to
resolveat(2) in the future.
Signed-off-by: Aleksa Sarai
---
arch/alpha/include/uapi/asm/fcntl.h | 1 +
arch/parisc/include/uapi/asm/fc
n_how struct is padded to 64 bytes
for future extensions (all of the reserved bits must be zeroed).
[1]: https://github.com/openSUSE/libpathrs
Suggested-by: Christian Brauner
Signed-off-by: Aleksa Sarai
---
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
arch/arm/tools/syscall.tbl
tps://lwn.net/Articles/603929/
[5]: https://lwn.net/Articles/723057/
[6]: https://github.com/cyphar/filepath-securejoin
[7]: https://github.com/openSUSE/libpathrs
Aleksa Sarai (8):
namei: obey trailing magic-link DAC permissions
procfs: switch magic-link modes to be more sane
open: O_EMPTYPATH:
on the
now-disallowed functionality of upgrading an O_RDONLY descriptor to
O_RDWR.
Signed-off-by: Aleksa Sarai
---
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/memfd/memfd_test.c| 7 +-
tools/testing/selftests/openat2/.gitignore| 1 +
tools/testing
On 2019-08-24, Daniel Colascione wrote:
> On Mon, Aug 19, 2019 at 8:37 PM Aleksa Sarai wrote:
> >
> > The most obvious syscall to add support for the new LOOKUP_* scoping
> > flags would be openat(2). However, there are a few reasons why this is
> > no
On 2019-08-29, Rasmus Villemoes wrote:
> On 29/08/2019 14.15, Aleksa Sarai wrote:
> > On 2019-08-24, Daniel Colascione wrote:
>
> >> Why pad the structure when new functionality (perhaps accommodated via
> >> a larger structure) could be signaled by passing a
On 2019-09-05, Christian Brauner wrote:
> On Thu, Sep 05, 2019 at 06:19:22AM +1000, Aleksa Sarai wrote:
> > A common pattern for syscall extensions is increasing the size of a
> > struct passed from userspace, such that the zero-value of the new fields
> > result in the
On 2019-09-05, Christian Brauner wrote:
> On Thu, Sep 05, 2019 at 06:19:22AM +1000, Aleksa Sarai wrote:
> > A common pattern for syscall extensions is increasing the size of a
> > struct passed from userspace, such that the zero-value of the new fields
> > result in the
On 2019-09-05, Peter Zijlstra wrote:
> On Thu, Sep 05, 2019 at 07:26:22PM +1000, Aleksa Sarai wrote:
> > On 2019-09-05, Peter Zijlstra wrote:
> > > On Thu, Sep 05, 2019 at 06:19:22AM +1000, Aleksa Sarai wrote:
> > > > +
> >
On 2019-09-05, Peter Zijlstra wrote:
> On Thu, Sep 05, 2019 at 07:26:22PM +1000, Aleksa Sarai wrote:
> > On 2019-09-05, Peter Zijlstra wrote:
> > > On Thu, Sep 05, 2019 at 06:19:22AM +1000, Aleksa Sarai wrote:
> > > > +/**
> > > > + * copy_s
of
> userland memory zeroed or checked for non-zeroes - why would that
> be a problem?
Thinking about it some more, there isn't really any r/w amplification --
so there isn't much to gain by passing giant structs. Though, if we are
going to permit 2GB buffers, isn't that also an argument to use
memchr_inv(
On 2019-09-05, Al Viro wrote:
> On Thu, Sep 05, 2019 at 06:19:22AM +1000, Aleksa Sarai wrote:
> > +/*
> > + * "memset(p, 0, size)" but for user space buffers. Caller must have
> > already
> > + * checked access_ok(p, size).
> > + */
> > +s
On 2019-09-06, Al Viro wrote:
> On Fri, Sep 06, 2019 at 09:00:03AM +1000, Aleksa Sarai wrote:
> > > > + return -EFAULT;
> > > > + }
> > > > + /* Copy the interoperable parts of the struct. */
> >
users of the struct-extension pattern.
Cc: Christian Brauner
Signed-off-by: Aleksa Sarai
---
include/uapi/linux/sched.h | 2 ++
kernel/fork.c | 34 ++
2 files changed, 8 insertions(+), 28 deletions(-)
diff --git a/include/uapi/linux/sched.h b/include
619151/
[3]: https://lwn.net/Articles/603929/
[4]: https://lwn.net/Articles/723057/
Cc: Christian Brauner
Suggested-by: David Drysdale
Suggested-by: Al Viro
Suggested-by: Andy Lutomirski
Suggested-by: Linus Torvalds
Signed-off-by: Aleksa Sarai
---
fs/namei.c| 85 ++
t/Articles/603929/
[5]: https://lwn.net/Articles/723057/
[6]: https://github.com/cyphar/filepath-securejoin
[7]: https://github.com/openSUSE/libpathrs
Aleksa Sarai (12):
lib: introduce copy_struct_{to,from}_user helpers
clone3: switch to copy_struct_from_user()
sched_setattr: switch to copy_stru
The change is very straightforward, and takes advantage of the (very
minor) efficiency improvements in copy_struct_from_user() -- that the
memchr_inv() check is done on a buffer instead of one-at-at-time with
get_user().
Signed-off-by: Aleksa Sarai
---
kernel/events/core.c | 45
stworthiness to this
construction.
[*] It may be acceptable in the future to do a path_is_under() check
after resolving a magic-link and permit resolution if the
nd_jump_link() result is still within the dirfd. However this seems
unlikely to be a feature that people *really* need* -- i
On 2019-09-04, Linus Torvalds wrote:
> On Wed, Sep 4, 2019 at 1:23 PM Aleksa Sarai wrote:
> > This patch allows for LOOKUP_BENEATH and LOOKUP_IN_ROOT to safely permit
> > ".." resolution (in the case of LOOKUP_BENEATH the resolution will still
> > fail if "
The change is very straightforward, and takes advantage of the (very
minor) efficiency improvements in copy_struct_{to,from}_user() -- that
the memchr_inv() check is done on a buffer instead of one-at-at-time
with get_user() or put_user().
Signed-off-by: Aleksa Sarai
---
kernel/sched/core.c
for
writing (because it is the current->mm of a live process).
With the new O_PATH restrictions, changing the default mode of these
magic-links allows us to avoid delayed-access attacks such as we saw in
CVE-2019-5736.
Signed-off-by: Aleksa Sarai
---
fs/proc/base.c |
ase path
seems to be the most consistent behaviour (and also avoids foot-gunning
users who want to scope paths that are absolute).
[1]: https://github.com/cyphar/filepath-securejoin
Signed-off-by: Aleksa Sarai
---
fs/namei.c| 41 +++--
include/l
on the
now-disallowed functionality of upgrading an O_RDONLY descriptor to
O_RDWR.
Signed-off-by: Aleksa Sarai
---
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/memfd/memfd_test.c| 7 +-
tools/testing/selftests/openat2/.gitignore| 1 +
tools/testing
he
expense of further complicating O_PATH makes little sense. Ultimately,
if users ask for this we can always add RESOLVE_EMPTY_PATH to
resolveat(2) in the future.
Signed-off-by: Aleksa Sarai
---
arch/alpha/include/uapi/asm/fcntl.h | 1 +
arch/parisc/include/uapi/asm/fc
[1]: https://github.com/openSUSE/libpathrs
Suggested-by: Christian Brauner
Signed-off-by: Aleksa Sarai
---
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
arch/arm/tools/syscall.tbl | 1 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h
On 2019-09-05, Peter Zijlstra wrote:
> On Thu, Sep 05, 2019 at 11:43:05AM +0200, Peter Zijlstra wrote:
> > On Thu, Sep 05, 2019 at 07:26:22PM +1000, Aleksa Sarai wrote:
> > > On 2019-09-05, Peter Zijlstra wrote:
> > > > On Thu, Sep 05, 2019 at 06:19:
arguments.
Suggested-by: Rasmus Villemoes
Signed-off-by: Aleksa Sarai
---
include/linux/uaccess.h | 5 ++
lib/Makefile| 2 +-
lib/struct_user.c | 182
3 files changed, 188 insertions(+), 1 deletion(-)
create mode 100644 lib
rror and do not
cause any user-visible problems. In order to give users a heads-up, a
warning is output to dmesg whenever may_open_magiclink() refuses access.
[1]: http://git.altlinux.org/people/legion/packages/kbd.git
Suggested-by: Andy Lutomirski
Suggested-by: Christian Brauner
Signed-off-by: Al
On 2019-09-18, Aleksa Sarai wrote:
> On 2019-09-17, Jann Horn wrote:
> > On Wed, Sep 4, 2019 at 10:21 PM Aleksa Sarai wrote:
> > > The ability for userspace to "re-open" file descriptors through
> > > /proc/self/fd has been a very useful tool for all sorts
On 2019-09-17, Jann Horn wrote:
> On Wed, Sep 4, 2019 at 10:21 PM Aleksa Sarai wrote:
> > The ability for userspace to "re-open" file descriptors through
> > /proc/self/fd has been a very useful tool for all sorts of usecases
> > (container runtimes are one common
On 2019-09-07, Jeff Layton wrote:
> On Thu, 2019-09-05 at 06:19 +1000, Aleksa Sarai wrote:
> > + * @flags: O_* flags.
> > + * @mode: O_CREAT/O_TMPFILE file mode.
> > + * @upgrade_mask: UPGRADE_* flags (to restrict O_PATH re-opening).
> > + * @resolve: RESOLVE_*
On 2019-09-05, Peter Zijlstra wrote:
> On Thu, Sep 05, 2019 at 06:19:22AM +1000, Aleksa Sarai wrote:
> > +/**
> > + * copy_struct_to_user: copy a struct to user space
> > + * @dst: Destination address, in user space.
> > + * @usize: Size of @dst struct.
> > + *
On 2019-09-05, Rasmus Villemoes wrote:
> On 04/09/2019 22.19, Aleksa Sarai wrote:
> > A common pattern for syscall extensions is increasing the size of a
> > struct passed from userspace, such that the zero-value of the new fields
> > result in the old kernel behaviou
es/619151/
[4]: https://lwn.net/Articles/603929/
[5]: https://lwn.net/Articles/723057/
[6]: https://github.com/cyphar/filepath-securejoin
[7]: https://github.com/openSUSE/libpathrs
Aleksa Sarai (8):
namei: obey trailing magic-link DAC permissions
procfs: switch magic-link modes to be more sane
619151/
[3]: https://lwn.net/Articles/603929/
[4]: https://lwn.net/Articles/723057/
Cc: Christian Brauner
Suggested-by: David Drysdale
Suggested-by: Al Viro
Suggested-by: Andy Lutomirski
Suggested-by: Linus Torvalds
Signed-off-by: Aleksa Sarai
---
fs/namei.c| 85 ++
stworthiness to this
construction.
[*] It may be acceptable in the future to do a path_is_under() check
after resolving a magic-link and permit resolution if the
nd_jump_link() result is still within the dirfd. However this seems
unlikely to be a feature that people *really* need* -- i
ase path
seems to be the most consistent behaviour (and also avoids foot-gunning
users who want to scope paths that are absolute).
[1]: https://github.com/cyphar/filepath-securejoin
Suggested-by: Christian Brauner
Signed-off-by: Aleksa Sarai
---
fs/namei.c| 41
rror and do not
cause any user-visible problems. In order to give users a heads-up, a
warning is output to dmesg whenever may_open_magiclink() refuses access.
[1]: http://git.altlinux.org/people/legion/packages/kbd.git
Suggested-by: Andy Lutomirski
Suggested-by: Christian Brauner
Signed-off-by: Al
for
writing (because it is the current->mm of a live process).
With the new O_PATH restrictions, changing the default mode of these
magic-links allows us to avoid delayed-access attacks such as we saw in
CVE-2019-5736.
Signed-off-by: Aleksa Sarai
---
fs/proc/base.c |
n_how struct is padded to 64 bytes
for future extensions (all of the reserved bits must be zeroed).
[1]: https://github.com/openSUSE/libpathrs
Suggested-by: Christian Brauner
Signed-off-by: Aleksa Sarai
---
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
arch/arm/tools/syscall.tbl
on the
now-disallowed functionality of upgrading an O_RDONLY descriptor to
O_RDWR.
Signed-off-by: Aleksa Sarai
---
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/memfd/memfd_test.c| 7 +-
tools/testing/selftests/openat2/.gitignore| 1 +
tools/testing
he
expense of further complicating O_PATH makes little sense. Ultimately,
if users ask for this we can always add RESOLVE_EMPTY_PATH to
resolveat(2) in the future.
Signed-off-by: Aleksa Sarai
---
arch/alpha/include/uapi/asm/fcntl.h | 1 +
arch/parisc/include/uapi/asm/fc
On 2019-07-14, Al Viro wrote:
> On Sun, Jul 14, 2019 at 05:00:29PM +1000, Aleksa Sarai wrote:
> > The basic property being guaranteed by LOOKUP_IN_ROOT is that it will
> > not result in resolution of a path component which was not inside the
> > root of the dirfd tree
On 2019-07-18, Rasmus Villemoes wrote:
> On 06/07/2019 16.57, Aleksa Sarai wrote:
> > --- a/fs/open.c
> > +++ b/fs/open.c
> > @@ -928,24 +928,32 @@ struct file *open_with_fake_path(const struct path
> > *path, int flags,
> > }
> > EXPORT_SYMBOL(open_wi
On 2019-07-18, Arnd Bergmann wrote:
> On Sat, Jul 6, 2019 at 5:00 PM Aleksa Sarai wrote:
>
> > diff --git a/arch/alpha/kernel/syscalls/syscall.tbl
> > b/arch/alpha/kernel/syscalls/syscall.tbl
> > index 9e7704e44f6d..1703d048c141 100644
> > --- a/arch/alpha/kernel/
On 2019-07-19, Dmitry V. Levin wrote:
> On Sun, Jul 07, 2019 at 12:57:35AM +1000, Aleksa Sarai wrote:
> [...]
> > +/**
> > + * Arguments for how openat2(2) should open the target path. If @extra is
> > zero,
> > + * then openat2(2) is identical to openat(2).
>
l.org/patchwork/patch/784221/
[3]: https://lwn.net/Articles/619151/
[4]: https://lwn.net/Articles/603929/
[5]: https://lwn.net/Articles/723057/
[6]: https://github.com/cyphar/filepath-securejoin
[7]: https://github.com/openSUSE/libpathrs
Aleksa Sarai (9):
namei: obey trailing magic-link DAC permissions
rror and do not
cause any user-visible problems. In order to give users a heads-up, a
warning is output to dmesg whenever may_open_magiclink() refuses access.
[1]: http://git.altlinux.org/people/legion/packages/kbd.git
Co-developed-by: Andy Lutomirski
Co-developed-by: Christian Braune
for
writing (because it is the current->mm of a live process).
With the new O_PATH restrictions, changing the default mode of these
magic-links allows us to avoid delayed-access attacks such as we saw in
CVE-2019-5736.
Signed-off-by: Aleksa Sarai
---
fs/proc/base.c |
he
expense of further complicating O_PATH makes little sense. Ultimately,
if users ask for this we can always add RESOLVE_EMPTY_PATH to
resolveat(2) in the future.
Signed-off-by: Aleksa Sarai
---
arch/alpha/include/uapi/asm/fcntl.h | 1 +
arch/parisc/include/uapi/asm/fc
619151/
[3]: https://lwn.net/Articles/603929/
[4]: https://lwn.net/Articles/723057/
Cc: Christian Brauner
Suggested-by: David Drysdale
Suggested-by: Al Viro
Suggested-by: Andy Lutomirski
Suggested-by: Linus Torvalds
Signed-off-by: Aleksa Sarai
---
fs/namei.c| 85 ++
ase path
seems to be the most consistent behaviour (and also avoids foot-gunning
users who want to scope paths that are absolute).
[1]: https://github.com/cyphar/filepath-securejoin
Co-developed-by: Christian Brauner
Signed-off-by: Aleksa Sarai
---
fs/namei.c| 41
acceptable in the future to do a path_is_under() check
after resolving a magic-link and permit resolution if the
nd_jump_link() result is still within the dirfd. However this seems
unlikely to be a feature that people *really* need* -- it can be
added later if it turns out a lot of
n_how struct is padded to 64 bytes
for future extensions (all of the reserved bits must be zeroed).
[1]: https://github.com/openSUSE/libpathrs
Co-developed-by: Christian Brauner
Signed-off-by: Aleksa Sarai
---
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
arch/arm/tools
Previously, using "%m" in a ksft_* format string can result in strange
output because the errno value wasn't saved before calling other libc
functions. The solution is to simply save and restore the errno before
we format the user-supplied format string.
Signed-off-by: Aleksa Sarai
on the
now-disallowed functionality of upgrading an O_RDONLY descriptor to
O_RDWR.
Signed-off-by: Aleksa Sarai
---
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/memfd/memfd_test.c| 7 +-
tools/testing/selftests/openat2/.gitignore| 1 +
tools/testing
On 2019-07-19, shuah wrote:
> On 7/19/19 10:42 AM, Aleksa Sarai wrote:
> > Previously, using "%m" in a ksft_* format string can result in strange
> > output because the errno value wasn't saved before calling other libc
> > functions. The solution is to simply sa
g is basically "was filename_mountpoint()
> been called by umount(2) or has it come from an autofs ioctl?".
> And looking at the rationale in that commit, autofs ioctls need
> it just as much as umount(2) does. Why is it not set for those
> as well? And why is it conditional at all?
In addition, LOOKUP_NO_EVAL == LOOKUP_OPEN (0x100). Is that meant to be
the case? Also I just saw you have a patch in work.namei that fixes this
up -- do you want me to rebase on top of that?
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
ote to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see
> https://stackoverflow.com/a/37406982]
>
> url:
> https://github.com/0day-ci/linux/commits/Aleksa-Sarai/namei-openat2-2-path-resolution-restr
t version.
> url:
> https://github.com/0day-ci/linux/commits/Aleksa-Sarai/namei-openat2-2-path-resolution-restrictions/20191001-025628
> config: i386-defconfig (attached as .config)
> compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
> reproduce:
> # save the attached .con
for
writing (because it is the current->mm of a live process).
With the new O_PATH restrictions, changing the default mode of these
magic-links allows us to avoid delayed-access attacks such as we saw in
CVE-2019-5736.
Signed-off-by: Aleksa Sarai
---
fs/proc/base.c |
he
expense of further complicating O_PATH makes little sense. Ultimately,
if users ask for this we can always add RESOLVE_EMPTY_PATH to
resolveat(2) in the future.
Signed-off-by: Aleksa Sarai
---
arch/alpha/include/uapi/asm/fcntl.h | 1 +
arch/parisc/include/uapi/asm/fc
619151/
[3]: https://lwn.net/Articles/603929/
[4]: https://lwn.net/Articles/723057/
Cc: Christian Brauner
Suggested-by: David Drysdale
Suggested-by: Al Viro
Suggested-by: Andy Lutomirski
Suggested-by: Linus Torvalds
Signed-off-by: Aleksa Sarai
---
fs/namei.c| 135 ++
[1]: https://github.com/openSUSE/libpathrs
Suggested-by: Christian Brauner
Signed-off-by: Aleksa Sarai
---
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
arch/arm/tools/syscall.tbl | 1 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h
We've introduced new (somewhat subtle) behaviour regarding trailing
magic-links, so it's best to make sure everyone can follow along with
the reasoning behind trailing_magiclink().
Signed-off-by: Aleksa Sarai
---
Documentation/filesystems/path-lookup.rst | 80 ++-
1 file
work/patch/784221/
[3]: https://lwn.net/Articles/619151/
[4]: https://lwn.net/Articles/603929/
[5]: https://lwn.net/Articles/723057/
[6]: https://github.com/cyphar/filepath-securejoin
[7]: https://github.com/openSUSE/libpathrs
Aleksa Sarai (9):
namei: obey trailing magic-link DAC permissions
1 - 100 of 221 matches
Mail list logo
