From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754042AbcKSJds (ORCPT ); Sat, 19 Nov 2016 04:33:48 -0500 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:6656 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753308AbcKSJdp (ORCPT ); Sat, 19 Nov 2016 04:33:45 -0500 Date: Sat, 19 Nov 2016 10:33:26 +0100 From: Willy Tarreau To: "Eric W. Biederman" Cc: Linux Containers , Oleg Nesterov , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Linux FS Devel , Michal Hocko , Jann Horn , Kees Cook , Andy Lutomirski Subject: Re: [REVIEW][PATCH 0/3] Fixing ptrace vs exec vs userns interactions Message-ID: <20161119093326.GA13593@1wt.eu> References: <87y41kjn6l.fsf@xmission.com> <20161019172917.GE1210@laptop.thejh.net> <87pomwi5p2.fsf@xmission.com> <87pomwghda.fsf@xmission.com> <87twb6avk8.fsf_-_@xmission.com> <20161119071700.GA13347@1wt.eu> <20161119092804.GA13553@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161119092804.GA13553@1wt.eu> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 19, 2016 at 10:28:04AM +0100, Willy Tarreau wrote: > On Sat, Nov 19, 2016 at 08:17:00AM +0100, Willy Tarreau wrote: > > Hi Eric, > > > > On Thu, Nov 17, 2016 at 11:02:47AM -0600, Eric W. Biederman wrote: > > > > > > With everyone heading to Kernel Summit and Plumbers I put this set of > > > patches down temporarily. Now is the time to take it back up and to > > > make certain I am not missing something stupid in this set of patches. > > > > I couldn't get your patch set to apply to any of the kernels I tried, > > I manually adjusted some parts but the second one has too many rejects. > > What kernel should I apply this to ? Or maybe some preliminary patches > > are needed ? > > OK I finally managed to get it to work on top of 4.8.9 (required less changes > than master). I also had to drop the user_ns changes since there's no such > user_ns in mm_struct there. > > I could run a test on it, that looks reasonable : > > FS: > > admin@vm:~$ strace -e trace=fstat,uname,ioctl,open uname > open(0x7ffd01bbeeb0, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open(0x7ffd01bbeeb0, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open(0x7ffd01bbeeb0, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open(0x7ffd01bbeeb0, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open(0x7f3f9a1663e3, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open(0x7ffd01bbeeb0, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open(0x7ffd01bbeeb0, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open(0x7ffd01bbeeb0, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open(0x7ffd01bbeeb0, O_RDONLY|O_CLOEXEC) = 3 > fstat(3, {...}) = 0 > open(0x7ffd01bbee80, O_RDONLY|O_CLOEXEC) = 3 > fstat(3, {...}) = 0 > uname({...}) = 0 > fstat(1, {...}) = 0 > ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7ffd01bbf400) = 0 > > admin@vm:~$ sudo strace -e trace=fstat,uname,ioctl,open uname > open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open("/lib64/tls/x86_64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open("/lib64/tls/libpthread.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open("/lib64/x86_64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open("/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3 > fstat(3, {st_mode=S_IFREG|0555, st_size=101312, ...}) = 0 > open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 > fstat(3, {st_mode=S_IFREG|0555, st_size=1479016, ...}) = 0 > uname({sys="Linux", node="vm", ...}) = 0 > fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(4, 64), ...}) = 0 > ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 opost isig icanon echo ...}) = 0 > > Network: > > admin@vm:~$ strace -e trace=socket,setsockopt,connect /tmp/nc 198.18.3 22 > socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 > connect(3, {...}, 110) = -1 ENOENT (No such file or directory) > socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 > connect(3, {...}, 110) = -1 ENOENT (No such file or directory) > socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 > setsockopt(3, SOL_SOCKET, SO_REUSEADDR, 0x7ffd2c26bdbc, 4) = 0 > connect(3, {...}, 16) = 0 > > admin@vm:~$ sudo strace -e trace=socket,setsockopt,connect /tmp/nc 198.18.3 22 > socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 > connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) > socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 > connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) > socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 > setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 > connect(3, {sa_family=AF_INET, sin_port=htons(22), sin_addr=inet_addr("198.18.0.3")}, 16) = 0 > > So in short now we can at least see what syscall fails eventhough we can't > know why. I think it can be an acceptable trade-off. I also tested with gdb and it behaves as desired : admin@vm:~$ sleep 100000 & [1] 1615 admin@vm:~$ /tmp/gdb-x86_64 -q -p 1615 Attaching to process 1615 ptrace: Operation not permitted. (gdb) quit admin@vm:~$ sudo cp /bin/sleep /var/tmp/ admin@vm:~$ sudo chmod 755 /var/tmp/sleep admin@vm:~$ /tmp/sleep 100000 & [1] 1620 admin@vm:~$ /tmp/gdb-x86_64 -q -p 1620 Attaching to process 1620 Reading symbols from /var/tmp/sleep...(no debugging symbols found)...done. (...) 0x00007f6723d561b0 in nanosleep () from /lib64/libpthread.so.0 (gdb) quit Willy From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sat, 19 Nov 2016 10:33:26 +0100 From: Willy Tarreau To: "Eric W. Biederman" Cc: Linux Containers , Oleg Nesterov , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Linux FS Devel , Michal Hocko , Jann Horn , Kees Cook , Andy Lutomirski Subject: Re: [REVIEW][PATCH 0/3] Fixing ptrace vs exec vs userns interactions Message-ID: <20161119093326.GA13593@1wt.eu> References: <87y41kjn6l.fsf@xmission.com> <20161019172917.GE1210@laptop.thejh.net> <87pomwi5p2.fsf@xmission.com> <87pomwghda.fsf@xmission.com> <87twb6avk8.fsf_-_@xmission.com> <20161119071700.GA13347@1wt.eu> <20161119092804.GA13553@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161119092804.GA13553@1wt.eu> Sender: owner-linux-mm@kvack.org List-ID: On Sat, Nov 19, 2016 at 10:28:04AM +0100, Willy Tarreau wrote: > On Sat, Nov 19, 2016 at 08:17:00AM +0100, Willy Tarreau wrote: > > Hi Eric, > > > > On Thu, Nov 17, 2016 at 11:02:47AM -0600, Eric W. Biederman wrote: > > > > > > With everyone heading to Kernel Summit and Plumbers I put this set of > > > patches down temporarily. Now is the time to take it back up and to > > > make certain I am not missing something stupid in this set of patches. > > > > I couldn't get your patch set to apply to any of the kernels I tried, > > I manually adjusted some parts but the second one has too many rejects. > > What kernel should I apply this to ? Or maybe some preliminary patches > > are needed ? > > OK I finally managed to get it to work on top of 4.8.9 (required less changes > than master). I also had to drop the user_ns changes since there's no such > user_ns in mm_struct there. > > I could run a test on it, that looks reasonable : > > FS: > > admin@vm:~$ strace -e trace=fstat,uname,ioctl,open uname > open(0x7ffd01bbeeb0, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open(0x7ffd01bbeeb0, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open(0x7ffd01bbeeb0, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open(0x7ffd01bbeeb0, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open(0x7f3f9a1663e3, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open(0x7ffd01bbeeb0, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open(0x7ffd01bbeeb0, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open(0x7ffd01bbeeb0, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open(0x7ffd01bbeeb0, O_RDONLY|O_CLOEXEC) = 3 > fstat(3, {...}) = 0 > open(0x7ffd01bbee80, O_RDONLY|O_CLOEXEC) = 3 > fstat(3, {...}) = 0 > uname({...}) = 0 > fstat(1, {...}) = 0 > ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7ffd01bbf400) = 0 > > admin@vm:~$ sudo strace -e trace=fstat,uname,ioctl,open uname > open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open("/lib64/tls/x86_64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open("/lib64/tls/libpthread.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open("/lib64/x86_64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > open("/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3 > fstat(3, {st_mode=S_IFREG|0555, st_size=101312, ...}) = 0 > open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 > fstat(3, {st_mode=S_IFREG|0555, st_size=1479016, ...}) = 0 > uname({sys="Linux", node="vm", ...}) = 0 > fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(4, 64), ...}) = 0 > ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 opost isig icanon echo ...}) = 0 > > Network: > > admin@vm:~$ strace -e trace=socket,setsockopt,connect /tmp/nc 198.18.3 22 > socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 > connect(3, {...}, 110) = -1 ENOENT (No such file or directory) > socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 > connect(3, {...}, 110) = -1 ENOENT (No such file or directory) > socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 > setsockopt(3, SOL_SOCKET, SO_REUSEADDR, 0x7ffd2c26bdbc, 4) = 0 > connect(3, {...}, 16) = 0 > > admin@vm:~$ sudo strace -e trace=socket,setsockopt,connect /tmp/nc 198.18.3 22 > socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 > connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) > socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 > connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) > socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 > setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 > connect(3, {sa_family=AF_INET, sin_port=htons(22), sin_addr=inet_addr("198.18.0.3")}, 16) = 0 > > So in short now we can at least see what syscall fails eventhough we can't > know why. I think it can be an acceptable trade-off. I also tested with gdb and it behaves as desired : admin@vm:~$ sleep 100000 & [1] 1615 admin@vm:~$ /tmp/gdb-x86_64 -q -p 1615 Attaching to process 1615 ptrace: Operation not permitted. (gdb) quit admin@vm:~$ sudo cp /bin/sleep /var/tmp/ admin@vm:~$ sudo chmod 755 /var/tmp/sleep admin@vm:~$ /tmp/sleep 100000 & [1] 1620 admin@vm:~$ /tmp/gdb-x86_64 -q -p 1620 Attaching to process 1620 Reading symbols from /var/tmp/sleep...(no debugging symbols found)...done. (...) 0x00007f6723d561b0 in nanosleep () from /lib64/libpthread.so.0 (gdb) quit Willy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org