From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759338AbdDSDFe (ORCPT ); Tue, 18 Apr 2017 23:05:34 -0400 Received: from smtpbg65.qq.com ([103.7.28.233]:18624 "EHLO smtpbg65.qq.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759243AbdDSDFc (ORCPT ); Tue, 18 Apr 2017 23:05:32 -0400 X-QQ-GoodBg: 0 X-QQ-SSF: 00100000000000F0 X-QQ-FEAT: Tp2hW+Mew+dcLPLa4X+F1Z/bnIBlmcEE4zrewO33+xEB5JoaSH4QsDUfuI738 SUzVo7bpLtCapTCVECSlt4Fu/KEELJZh0Zz3LF84yFeZyp7Vrm68dRYiPiFo3ZXU4X5kt+b M82/8hDHwQvGhuRp944H10MEnwbRQ0B0Xr573rVK0YhReucc4zYLBJKCH+i+3IBJvpHAbuo 4ezMdjI9kzsWODjY5Zc7bzxJuvapM68uAcv/m6HeHee4IcSWTe4m7XtYpTiExhiU= X-QQ-BUSINESS-ORIGIN: 2 X-Originating-IP: 73.231.152.12 X-QQ-STYLE: X-QQ-mid: bizmailneweng1t1492571128t983 From: "=?ISO-8859-1?B?aWNlYm95?=" To: "=?ISO-8859-1?B?bGludXgta2VybmVs?=" Subject: Potential bug in path handling Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Wed, 19 Apr 2017 11:05:27 +0800 X-Priority: 3 Message-ID: X-QQ-MIME: TCMime 1.0 by Tencent X-Mailer: QQMail 2.x X-QQ-Mailer: QQMail 2.x X-QQ-SENDSIZE: 520 X-QQ-Bgrelay: 1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v3J35hKd023559 I found this while writing a simple sandbox. Script to reproduce: https://gist.github.com/iceb0y/93e77e6945019d8a863b452e18a18079 In the `bugbox`: bugbox-4.3$ ls bin (you get the files in /bin) however bugbox-4.3$ ls ../bin (nothing) Tried with latest 4.11 kernel. The problem occurs when you bind mount `/` to itself, and then remount it. Looks like one of the mount namespace, bind mount or pivot_root is mishandling root barrier, causing `../bin` referencing to the `bin` directory instead of the bind mount. This could be a security problem. Any idea on what's the problem, or how to debug this? * Dependencies of `bugbox`: python 2 or 3 the `butter` package for syscall (sorry) /bin /lib and /lib64 on your system are real, not symlinks