Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall

Jeff Layton writes: > On Mon, 2019-08-26 at 19:50 +, sba...@catern.com wrote: >> Aleksa Sarai writes: >> > To this end, we introduce the openat2(2) syscall. It provides all of the >> > features of openat(2) through the @how->flags argument, but also >> > also provides a new @how->resolve

Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall

On Mon, 2019-08-26 at 19:50 +, sba...@catern.com wrote: > Aleksa Sarai writes: > > To this end, we introduce the openat2(2) syscall. It provides all of the > > features of openat(2) through the @how->flags argument, but also > > also provides a new @how->resolve argument which exposes

Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall

Aleksa Sarai writes: > To this end, we introduce the openat2(2) syscall. It provides all of the > features of openat(2) through the @how->flags argument, but also > also provides a new @how->resolve argument which exposes RESOLVE_* flags > that map to our new LOOKUP_* flags. It also eliminates

Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall

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 > not the best course of action: > > * The new LOOKUP_* flags are intended to be security

Re: [PATCH 05/26] openrisc: map as uncached in ioremap

On Sat, Aug 17, 2019 at 09:32:32AM +0200, Christoph Hellwig wrote: > Openrisc is the only architecture not mapping ioremap as uncached, > which has been the default since the Linux 2.6.x days. Switch it > over to implement uncached semantics by default. > > Signed-off-by: Christoph Hellwig >

HERZLICHEN GLÜCKWUNSCH € 1,000.000,00 wurde an Sie gespendet

Ich bin der Vorsitzende von Wipro Limited. Ich habe 25 Prozent meines persönlichen Vermögens verschenkt für die Wohlfahrt. Und ich habe zugesagt, den Rest von 25% dieses Jahr 2019 an zu vergeben Privatpersonen .. Ich habe mich entschieden, Ihnen €1.000.000,00 zu spenden. Wenn du bist Interesse an

Wohltätigkeitsspende von 2.000.000 Millionen Euro

Lieber Freund, Ich bin Herr Tayeb Souami, New Jersey, Vereinigte Staaten von Amerika, der Mega-Gewinner von $ 315million In Mega Millions Jackpot, spende ich an 5 zufällige Personen, wenn Sie diese E-Mail erhalten, dann wurde Ihre E-Mail nach einem Spinball ausgewählt.Ich habe den größten Teil

MY $25,000,000.00 INVESTMENT PROPOSAL WITH YOU AND IN YOUR COUNTRY.

-- Dear, With due respect this is not spam or Scam mail, because I have contacted you before and there was no response from you,I apologise if the contents of this mail are contrary to your moral ethics, which I feel may be of great disturbance to your person, but please treat this with absolute

[PATCH RESEND v11 6/8] namei: aggressively check for nd->root escape on ".." resolution

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 ".." resolution would resolve a path outside of the root -- while LOOKUP_IN_ROOT will chroot(2)-style scope it). Magic-link jumps are still

[PATCH RESEND v11 8/8] selftests: add openat2(2) selftests

Test all of the various openat2(2) flags, as well as how file descriptor re-opening works. A small stress-test of a symlink-rename attack is included to show that the protections against ".."-based attacks are sufficient. In addition, the memfd selftest is fixed to no longer depend on the

[PATCH RESEND v11 7/8] open: openat2(2) syscall

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 not the best course of action: * The new LOOKUP_* flags are intended to be security features, and openat(2) will silently ignore all unknown flags. This

[PATCH RESEND v11 4/8] namei: O_BENEATH-style path resolution flags

Add the following flags to allow various restrictions on path resolution (these affect the *entire* resolution, rather than just the final path component -- as is the case with LOOKUP_FOLLOW). The primary justification for these flags is to allow for programs to be far more strict about how they

[PATCH RESEND v11 5/8] namei: LOOKUP_IN_ROOT: chroot-like path resolution

The primary motivation for the need for this flag is container runtimes which have to interact with malicious root filesystems in the host namespaces. One of the first requirements for a container runtime to be secure against a malicious rootfs is that they correctly scope symlinks (that is, they

[PATCH RESEND v11 3/8] open: O_EMPTYPATH: procfs-less file descriptor re-opening

Userspace has made use of /proc/self/fd very liberally to allow for descriptors to be re-opened. There are a wide variety of uses for this feature, but it has always required constructing a pathname and could not be done without procfs mounted. The obvious solution for this is to extend openat(2)

[PATCH RESEND v11 2/8] procfs: switch magic-link modes to be more sane

Now that magic-link modes are obeyed for file re-opening purposes, some of the pre-existing magic-link modes need to be adjusted to be more semantically correct. The most blatant example of this is /proc/self/exe, which had a mode of a+rwx even though tautologically the file could never be opened

[PATCH RESEND v11 1/8] namei: obey trailing magic-link DAC permissions

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 example). However, the current interface for doing this has resulted in some pretty subtle security holes. Userspace can re-open a

[PATCH RESEND v11 0/8] openat2(2)

This patchset is being developed here: Patch changelog: v11: [RESEND: ] * Fix checkpatch.pl errors and warnings where reasonable. * Minor cleanup to pr_warn

PLEASE CONFIRM PURCHASE ORDER

Could you please confirm if your recieved our purchase order last week. If no please confirm let me resend it to you. NARESH KUMAR Executive Purchase Saiapextrading Ltd Dubai, KSA. (T/F): +96-2667-264 777 / 778 (Mo): +96 94284 02803 Website - http://www.saiapexgeneraltrading.com

Re: [PATCH] arch/alpha: Remove dead code

On Sun, Aug 4, 2019 at 12:50 AM Al Viro wrote: > > On Sun, Aug 04, 2019 at 12:47:36AM +0530, Souptick Joarder wrote: > > These are dead code since 2.6.11. If there is no plan to use > > it further, this can be removed forever. > > What's the point in removing ifdefed-out debugging printks? If

Re: [PATCH] arch/alpha: Remove dead code

On Sun, Aug 04, 2019 at 12:47:36AM +0530, Souptick Joarder wrote: > These are dead code since 2.6.11. If there is no plan to use > it further, this can be removed forever. What's the point in removing ifdefed-out debugging printks?

[PATCH] arch/alpha: Remove dead code

These are dead code since 2.6.11. If there is no plan to use it further, this can be removed forever. Signed-off-by: Souptick Joarder --- arch/alpha/boot/bootpz.c | 6 -- arch/alpha/kernel/core_irongate.c | 20 -- arch/alpha/kernel/core_polaris.c | 3 ---

[PATCH v2] alpha: Replace strncmp with str_has_prefix

In commit b6b2735514bc ("tracing: Use str_has_prefix() instead of using fixed sizes") the newly introduced str_has_prefix() was used to replace error-prone strncmp(str, const, len). Here fix codes with the same pattern. Signed-off-by: Chuhong Yuan --- Changes in v2: - Revise the indent and

Re: [PATCH] alpha: Replace strncmp with str_has_prefix

On Tue, 2019-07-30 at 10:44 +0800, Chuhong Yuan wrote: > In commit b6b2735514bc > ("tracing: Use str_has_prefix() instead of using fixed sizes") > the newly introduced str_has_prefix() was used > to replace error-prone strncmp(str, const, len). > Here fix codes with the same pattern. > >

[PATCH] alpha: Replace strncmp with str_has_prefix

In commit b6b2735514bc ("tracing: Use str_has_prefix() instead of using fixed sizes") the newly introduced str_has_prefix() was used to replace error-prone strncmp(str, const, len). Here fix codes with the same pattern. Signed-off-by: Chuhong Yuan --- arch/alpha/boot/tools/objstrip.c | 3 ++-

[PATCH v11 8/8] selftests: add openat2(2) selftests

Test all of the various openat2(2) flags, as well as how file descriptor re-opening works. A small stress-test of a symlink-rename attack is included to show that the protections against ".."-based attacks are sufficient. In addition, the memfd selftest is fixed to no longer depend on the

[PATCH v11 6/8] namei: aggressively check for nd->root escape on ".." resolution

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 ".." resolution would resolve a path outside of the root -- while LOOKUP_IN_ROOT will chroot(2)-style scope it). Magic-link jumps are still

[PATCH v11 5/8] namei: LOOKUP_IN_ROOT: chroot-like path resolution

The primary motivation for the need for this flag is container runtimes which have to interact with malicious root filesystems in the host namespaces. One of the first requirements for a container runtime to be secure against a malicious rootfs is that they correctly scope symlinks (that is, they

[PATCH v11 3/8] open: O_EMPTYPATH: procfs-less file descriptor re-opening

Userspace has made use of /proc/self/fd very liberally to allow for descriptors to be re-opened. There are a wide variety of uses for this feature, but it has always required constructing a pathname and could not be done without procfs mounted. The obvious solution for this is to extend openat(2)

[PATCH v11 2/8] procfs: switch magic-link modes to be more sane

Now that magic-link modes are obeyed for file re-opening purposes, some of the pre-existing magic-link modes need to be adjusted to be more semantically correct. The most blatant example of this is /proc/self/exe, which had a mode of a+rwx even though tautologically the file could never be opened

[PATCH v11 0/8] namei: openat2(2) path resolution restrictions

This patch is being developed here (with snapshots of each series version being stashed in separate branches with names of the form "resolveat/vX-summary"): Patch changelog: v11: * Fix checkpatch.pl errors and warnings where

[PATCH 3/5] arch: wire-up pidfd_wait()

This wires up the pidfd_wait() syscall into all arches at once. Signed-off-by: Christian Brauner Cc: Arnd Bergmann Cc: "Eric W. Biederman" Cc: Kees Cook Cc: Joel Fernandes (Google) Cc: Thomas Gleixner Cc: Jann Horn Cc: David Howells Cc: Andy Lutomirsky Cc: Andrew Morton Cc: Oleg

Great News: National Heart Center Singapore CT Coronary Calcium Score 18 July 2019

Subject: Great News: National Heart Center Singapore CT Coronary Calcium Score 18 July 2019 Good day from Singapore, This is good news for trillions and trillions of years to come! 1. My weight/mass is 123.5 kg (taken on 23 July 2019). 2. My height is 1.79 meters (taken on 23 July 2019). 3.

RE

Dear: Yokohama Rubber Manufacturing Company requires a reputable individual and company representation for our delinquent accounts customers in America and North America. We are seeking for representation for our business interest in America and North America. We are currently having a high

Re: [PATCH v10 8/9] kselftest: save-and-restore errno to allow for %m formatting

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 save and restore the errno before >

Re: [PATCH v10 8/9] kselftest: save-and-restore errno to allow for %m formatting

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 save and restore the errno before we format the user-supplied format string.

[PATCH v10 9/9] selftests: add openat2(2) selftests

Test all of the various openat2(2) flags, as well as how file descriptor re-opening works. A small stress-test of a symlink-rename attack is included to show that the protections against ".."-based attacks are sufficient. In addition, the memfd selftest is fixed to no longer depend on the

[PATCH v10 8/9] kselftest: save-and-restore errno to allow for %m formatting

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 ---

[PATCH v10 7/9] open: openat2(2) syscall

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 not the best course of action: * The new LOOKUP_* flags are intended to be security features, and openat(2) will silently ignore all unknown flags. This

[PATCH v10 6/9] namei: aggressively check for nd->root escape on ".." resolution

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 ".." resolution would resolve a path outside of the root -- while LOOKUP_IN_ROOT will chroot(2)-style scope it). Magic-link jumps are still

[PATCH v10 4/9] namei: O_BENEATH-style path resolution flags

Add the following flags to allow various restrictions on path resolution (these affect the *entire* resolution, rather than just the final path component -- as is the case with LOOKUP_FOLLOW). The primary justification for these flags is to allow for programs to be far more strict about how they

[PATCH v10 5/9] namei: LOOKUP_IN_ROOT: chroot-like path resolution

The primary motivation for the need for this flag is container runtimes which have to interact with malicious root filesystems in the host namespaces. One of the first requirements for a container runtime to be secure against a malicious rootfs is that they correctly scope symlinks (that is, they

[PATCH v10 3/9] open: O_EMPTYPATH: procfs-less file descriptor re-opening

Userspace has made use of /proc/self/fd very liberally to allow for descriptors to be re-opened. There are a wide variety of uses for this feature, but it has always required constructing a pathname and could not be done without procfs mounted. The obvious solution for this is to extend openat(2)

[PATCH v10 1/9] namei: obey trailing magic-link DAC permissions

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 example). However, the current interface for doing this has resulted in some pretty subtle security holes. Userspace can re-open a

[PATCH v10 2/9] procfs: switch magic-link modes to be more sane

Now that magic-link modes are obeyed for file re-opening purposes, some of the pre-existing magic-link modes need to be adjusted to be more semantically correct. The most blatant example of this is /proc/self/exe, which had a mode of a+rwx even though tautologically the file could never be opened

[PATCH v10 0/9] namei: openat2(2) path resolution restrictions

This patch is being developed here (with snapshots of each series version being stashed in separate branches with names of the form "resolveat/vX-summary"): Patch changelog: v10: * Ensure that unlazy_walk() will fail if we are in a

Re: [PATCH 1/2] arch: mark syscall number 435 reserved for clone3

On Fri, Jul 19, 2019 at 09:13:16PM +1000, Michael Ellerman wrote: > Christian Brauner writes: > > On Fri, Jul 19, 2019 at 08:18:02PM +1000, Michael Ellerman wrote: > >> Christian Brauner writes: > >> > On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote: > >> >> I think Vasily

Re: [PATCH 1/2] arch: mark syscall number 435 reserved for clone3

Christian Brauner writes: > On Fri, Jul 19, 2019 at 08:18:02PM +1000, Michael Ellerman wrote: >> Christian Brauner writes: >> > On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote: >> >> I think Vasily already has a clone3 patch for s390x with 435. >> > >> > A quick follow-up

Re: [PATCH v9 08/10] open: openat2(2) syscall

On Fri, Jul 19, 2019 at 05:12:18AM +0300, Dmitry V. Levin wrote: > On Thu, Jul 18, 2019 at 11:29:50PM +0200, Arnd Bergmann wrote: > [...] > > 5. you get the same problem with seccomp and strace that > >clone3() has -- these and others only track the register > >arguments by default. > >

Re: [PATCH 1/2] arch: mark syscall number 435 reserved for clone3

On Fri, Jul 19, 2019 at 08:18:02PM +1000, Michael Ellerman wrote: > Christian Brauner writes: > > On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote: > >> I think Vasily already has a clone3 patch for s390x with 435. > > > > A quick follow-up on this. Helge and Michael have

Re: [PATCH 1/2] arch: mark syscall number 435 reserved for clone3

Christian Brauner writes: > On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote: >> I think Vasily already has a clone3 patch for s390x with 435. > > A quick follow-up on this. Helge and Michael have asked whether there > are any tests for clone3. Yes, there will be and I try

Re: [PATCH v9 08/10] open: openat2(2) syscall

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). > > + * > > + * @flags: O_* flags

Re: [PATCH v9 08/10] open: openat2(2) syscall

On Thu, Jul 18, 2019 at 11:29:50PM +0200, Arnd Bergmann wrote: [...] > 5. you get the same problem with seccomp and strace that >clone3() has -- these and others only track the register >arguments by default. Just for the record, this is definitely not the case for strace: it decodes

Re: [PATCH v9 08/10] open: openat2(2) syscall

On Thu, Jul 18, 2019 at 6:12 PM Aleksa Sarai wrote: > On 2019-07-18, Arnd Bergmann wrote: > > On Sat, Jul 6, 2019 at 5:00 PM Aleksa Sarai wrote: > > > > In fact, that seems similar enough to the existing openat() that I think > > you could also just add the fifth argument to the existing call

Re: [PATCH v9 08/10] open: openat2(2) syscall

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_with_fake_path); > > > > -static inline

Re: [PATCH v9 08/10] open: openat2(2) syscall

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/syscalls/syscall.tbl > +++ b/arch/alpha/kernel/syscalls/syscall.tbl > @@ -461,6

Re: [PATCH v9 08/10] open: openat2(2) syscall

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_with_fake_path); > > -static inline int build_open_flags(int flags, umode_t mode, struct >

Re: [PATCH v9 05/10] namei: O_BENEATH-style path resolution flags

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 at some point during

If interested

My name is Mr. Allen, I have a Business Proposal of Four million five hundred thousand united states dollars for you to handle with me from my bank. I will need you to assist me in executing this Business .

Re: [PATCH v2 4/4] tools: Add fchmodat4

Em Tue, Jul 16, 2019 at 06:27:19PM -0700, Palmer Dabbelt escreveu: > I'm not sure why it's necessary to add this explicitly to tools/ as well > as arch/, but there were a few instances of fspick in here so I blindly > added fchmodat4 in the same fashion. The copies in tools/ for these specific

Re: [PATCH v2 2/4] Add fchmodat4(), a new syscall

On Tue, Jul 16, 2019 at 10:40:46PM -0400, Rich Felker wrote: > On Tue, Jul 16, 2019 at 06:27:17PM -0700, Palmer Dabbelt wrote: > > man 3p says that fchmodat() takes a flags argument, but the Linux > > syscall does not. There doesn't appear to be a good userspace > > workaround for this issue but

Re: [PATCH v2 2/4] Add fchmodat4(), a new syscall

On Tue, Jul 16, 2019 at 06:27:17PM -0700, Palmer Dabbelt wrote: > man 3p says that fchmodat() takes a flags argument, but the Linux > syscall does not. There doesn't appear to be a good userspace > workaround for this issue but the implementation in the kernel is pretty > straight-forward. The

Re: [PATCH v2 2/4] Add fchmodat4(), a new syscall

On Tue, 16 Jul 2019 18:48:02 PDT (-0700), v...@zeniv.linux.org.uk wrote: On Tue, Jul 16, 2019 at 06:27:17PM -0700, Palmer Dabbelt wrote: -int do_fchmodat(int dfd, const char __user *filename, umode_t mode) +int do_fchmodat4(int dfd, const char __user *filename, umode_t mode, int flags) {

Re: [PATCH v2 2/4] Add fchmodat4(), a new syscall

On Tue, Jul 16, 2019 at 06:27:17PM -0700, Palmer Dabbelt wrote: > -int do_fchmodat(int dfd, const char __user *filename, umode_t mode) > +int do_fchmodat4(int dfd, const char __user *filename, umode_t mode, int > flags) > { > struct path path; > int error; > - unsigned int

Add a new fchmodat4() syscall, v2

This patch set adds fchmodat4(), a new syscall. The actual implementation is super simple: essentially it's just the same as fchmodat(), but LOOKUP_FOLLOW is conditionally set based on the flags. I've attempted to make this match "man 2 fchmodat" as closely as possible, which says EINVAL is

[PATCH v2 2/4] Add fchmodat4(), a new syscall

man 3p says that fchmodat() takes a flags argument, but the Linux syscall does not. There doesn't appear to be a good userspace workaround for this issue but the implementation in the kernel is pretty straight-forward. The specific use case where the missing flags came up was WRT a fuse

[PATCH v2 3/4] arch: Register fchmodat4, usually as syscall 434

This registers the new fchmodat4 syscall in most places as nuber 434, with alpha being the exception where it's 544. I found all these sites by grepping for fspick, which I assume has found me everything. Signed-off-by: Palmer Dabbelt --- arch/alpha/kernel/syscalls/syscall.tbl | 1 +

[PATCH v2 4/4] tools: Add fchmodat4

I'm not sure why it's necessary to add this explicitly to tools/ as well as arch/, but there were a few instances of fspick in here so I blindly added fchmodat4 in the same fashion. Signed-off-by: Palmer Dabbelt --- tools/include/uapi/asm-generic/unistd.h | 4 +++-

[PATCH v2 1/4] Non-functional cleanup of a "__user * filename"

The next patch defines a very similar interface, which I copied from this definition. Since I'm touching it anyway I don't see any reason not to just go fix this one up. Signed-off-by: Palmer Dabbelt --- include/linux/syscalls.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH 1/2] arch: mark syscall number 435 reserved for clone3

On 16.07.19 20:55, Christian Brauner wrote: On Tue, Jul 16, 2019 at 08:53:10PM +0200, Sven Schnelle wrote: Hi, [Adding Helge to CC list] On Tue, Jul 16, 2019 at 03:06:33PM +0200, Christian Brauner wrote: On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote: I think Vasily

Re: [PATCH 1/2] arch: mark syscall number 435 reserved for clone3

Hi, [Adding Helge to CC list] On Tue, Jul 16, 2019 at 03:06:33PM +0200, Christian Brauner wrote: > On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote: > > I think Vasily already has a clone3 patch for s390x with 435. > > A quick follow-up on this. Helge and Michael have

Re: [PATCH 1/2] arch: mark syscall number 435 reserved for clone3

On Tue, Jul 16, 2019 at 08:53:10PM +0200, Sven Schnelle wrote: > Hi, > > [Adding Helge to CC list] > > On Tue, Jul 16, 2019 at 03:06:33PM +0200, Christian Brauner wrote: > > On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote: > > > I think Vasily already has a clone3 patch for

Re: [PATCH 1/2] arch: mark syscall number 435 reserved for clone3

On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote: > I think Vasily already has a clone3 patch for s390x with 435. A quick follow-up on this. Helge and Michael have asked whether there are any tests for clone3. Yes, there will be and I try to have them ready by the end of the

Re: [PATCH v9 05/10] namei: O_BENEATH-style path resolution flags

On 2019-07-14, Al Viro wrote: > On Sat, Jul 13, 2019 at 03:41:53AM +0100, Al Viro wrote: > > On Fri, Jul 12, 2019 at 04:00:26PM +0100, Al Viro wrote: > > > On Fri, Jul 12, 2019 at 02:25:53PM +0100, Al Viro wrote: > > > > > > > if (flags & LOOKUP_BENEATH) { > > > >

Re: [PATCH 1/2] arch: mark syscall number 435 reserved for clone3

On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote: > I think Vasily already has a clone3 patch for s390x with 435. Excellent. I'll leave the # 435 reserved for clone3 on s390x in until this patch has landed. It shouldn't be a merge conflict and if so it should be trivial.

Re: [PATCH 1/2] arch: mark syscall number 435 reserved for clone3

I think Vasily already has a clone3 patch for s390x with 435. On 14.07.19 21:22, Christian Brauner wrote: > A while ago Arnd made it possible to give new system calls the same > syscall number on all architectures (except alpha). To not break this > nice new feature let's mark 435 for clone3 as

Kindly Respond

Hello, I am Barr Fredrick Mbogo a business consultant i have a lucrative business to discuss with you from the Eastern part of Africa Uganda to be precise aimed at agreed percentage upon your acceptance of my hand in business and friendship. Kindly respond to me if you are interested to partner

Re: [PATCH v9 05/10] namei: O_BENEATH-style path resolution flags

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 at some point during resolution (and that all > absolute symlink

Re: [PATCH v9 05/10] namei: O_BENEATH-style path resolution flags

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 +2400,11 @@ static const char *path_init(struct

Re: [PATCH v9 01/10] namei: obey trailing magic-link DAC permissions

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 nameidata *p, int > > > > dfd, struct

Re: [PATCH v9 05/10] namei: O_BENEATH-style path resolution flags

On 2019-07-13, Al Viro wrote: > On Fri, Jul 12, 2019 at 04:00:26PM +0100, Al Viro wrote: > > On Fri, Jul 12, 2019 at 02:25:53PM +0100, Al Viro wrote: > > > > > if (flags & LOOKUP_BENEATH) { > > > nd->root = nd->path; > > > if (!(flags & LOOKUP_RCU)) > > >

Re: [PATCH v9 05/10] namei: O_BENEATH-style path resolution flags

On Sat, Jul 13, 2019 at 03:41:53AM +0100, Al Viro wrote: > On Fri, Jul 12, 2019 at 04:00:26PM +0100, Al Viro wrote: > > On Fri, Jul 12, 2019 at 02:25:53PM +0100, Al Viro wrote: > > > > > if (flags & LOOKUP_BENEATH) { > > > nd->root = nd->path; > > > if (!(flags &

Re: [PATCH v9 05/10] namei: O_BENEATH-style path resolution flags

On Fri, Jul 12, 2019 at 04:00:26PM +0100, Al Viro wrote: > On Fri, Jul 12, 2019 at 02:25:53PM +0100, Al Viro wrote: > > > if (flags & LOOKUP_BENEATH) { > > nd->root = nd->path; > > if (!(flags & LOOKUP_RCU)) > > path_get(>root); > > else

Facts in the Singapore Political Context

Subject/Topic: Facts in the Singapore Political Context 13 JULY 2019 Saturday Singapore Time Article: Why Singapore voters are asking for Santas Claus as their ideal politician to challenge the ruling party Online Platform: The Online Citizen (TOC) Author: Terry Xu (Singaporean, Chief Editor of

Re: [PATCH v9 00/10] namei: openat2(2) path resolution restrictions

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. > > * Add an openat2(O_CREAT) testcase.

Re: [PATCH v9 00/10] namei: openat2(2) path resolution restrictions

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. > * Add an openat2(O_CREAT) testcase. One general note for the future, BTW: for

Re: [PATCH v9 05/10] namei: O_BENEATH-style path resolution flags

On Fri, Jul 12, 2019 at 02:25:53PM +0100, Al Viro wrote: > if (flags & LOOKUP_BENEATH) { > nd->root = nd->path; > if (!(flags & LOOKUP_RCU)) > path_get(>root); > else > nd->root_seq = nd->seq; BTW, this

Re: [PATCH v9 05/10] namei: O_BENEATH-style path resolution flags

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 +2400,11 @@ static const char *path_init(struct nameidata > > > > > *nd, unsigned flags)

Re: [PATCH v9 01/10] namei: obey trailing magic-link DAC permissions

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 nameidata *p, int > > > dfd, struct filename *name) > > > p->stack =

Re: [PATCH v9 05/10] namei: O_BENEATH-style path resolution flags

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 +2400,11 @@ static const char *path_init(struct nameidata > > > > *nd, unsigned flags) > > > > s = ERR_PTR(error); > > > >

Re: [PATCH v9 05/10] namei: O_BENEATH-style path resolution flags

On Fri, Jul 12, 2019 at 08:57:45PM +1000, Aleksa Sarai wrote: > > > @@ -2350,9 +2400,11 @@ static const char *path_init(struct nameidata *nd, > > > unsigned flags) > > > s = ERR_PTR(error); > > > return s; > > > } > > > - error = dirfd_path_init(nd); > > > - if

Re: [PATCH v9 04/10] namei: split out nd->dfd handling to dirfd_path_init

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 to parse the > > > initial

Re: [PATCH v9 04/10] namei: split out nd->dfd handling to dirfd_path_init

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 different times (before or after

Re: [PATCH v9 05/10] namei: O_BENEATH-style path resolution flags

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) { > > - if (path_equal(>path, >root)) > > +

Re: [PATCH v9 01/10] namei: obey trailing magic-link DAC permissions

On Fri, Jul 12, 2019 at 05:14:54AM +0100, Al Viro wrote: > That's not quite guaranteed (it is possible to bind a symlink on top > of a regular file, and you will get LOOKUP_JUMPED on the entry into > trailing_symlink() when looking the result up). Moreover, why bother > with LOOKUP_JUMPED here?

Re: [PATCH v9 05/10] namei: O_BENEATH-style path resolution flags

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) { > - if (path_equal(>path, >root)) > + if (path_equal(>path, >root)) {

Re: [PATCH v9 04/10] namei: split out nd->dfd handling to dirfd_path_init

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 different times (before or after absolute path > handling) depending on

Re: [PATCH v9 01/10] namei: obey trailing magic-link DAC permissions

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 = dfd; > p->name = name; > - p->total_link_count = old ?

Re: [PATCH v9 10/10] selftests: add openat2(2) selftests

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 > > +++

Re: [PATCH v9 10/10] selftests: add openat2(2) selftests

Hi Aleksa, A few minor comments below. 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 > +++ b/tools/testing/selftests/openat2/Makefile > @@ -0,0

[PATCH v9 10/10] selftests: add openat2(2) selftests

Test all of the various openat2(2) flags, as well as how file descriptor re-opening works. A small stress-test of a symlink-rename attack is included to show that the protections against ".."-based attacks are sufficient. In addition, the memfd selftest is fixed to no longer depend on the

<    1   2   3   4   5   6   7   8   9   10   >