Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210522113155.244796-1-dong.menglong@zte.com.cn>
 <20210522113155.244796-2-dong.menglong@zte.com.cn> <YKxMjPOrHfb1uaA+@localhost>
 <CADxym3asj97wATjGthOyMzosg=dHY-bfk5pqLPYLSCa2Sub73Q@mail.gmail.com>
In-Reply-To: <CADxym3asj97wATjGthOyMzosg=dHY-bfk5pqLPYLSCa2Sub73Q@mail.gmail.com>
From:   Menglong Dong <menglong8.dong@gmail.com>
Date:   Tue, 25 May 2021 16:04:36 +0800
Message-ID: <CADxym3b8qTO-Fr9poZneZZsy5n3V1S3Fw6PqZ1YHb5=Ee28bUg@mail.gmail.com>
Subject: Re: [PATCH 1/3] init/main.c: introduce function ramdisk_exec_exist()
To:     Josh Triplett <josh@joshtriplett.org>
Cc:     Luis Chamberlain <mcgrof@kernel.org>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        Kees Cook <keescook@chromium.org>,
        Sami Tolvanen <samitolvanen@google.com>, johan@kernel.org,
        ojeda@kernel.org, jeyu@kernel.org, joe@perches.com,
        Menglong Dong <dong.menglong@zte.com.cn>, masahiroy@kernel.org,
        Jan Kara <jack@suse.cz>, Jens Axboe <axboe@kernel.dk>,
        hare@suse.de, gregkh@linuxfoundation.org, tj@kernel.org,
        song@kernel.org, NeilBrown <neilb@suse.de>,
        Andrew Morton <akpm@linux-foundation.org>,
        Barret Rhoden <brho@google.com>, f.fainelli@gmail.com,
        wangkefeng.wang@huawei.com, arnd@arndb.de,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>,
        mhiramat@kernel.org, Steven Rostedt <rostedt@goodmis.org>,
        vbabka@suse.cz, Alexander Potapenko <glider@google.com>,
        pmladek@suse.com, ebiederm@xmission.com, jojing64@gmail.com,
        linux-fsdevel@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, May 25, 2021 at 11:43 AM Menglong Dong <menglong8.dong@gmail.com> wrote:
>
> On Tue, May 25, 2021 at 9:02 AM Josh Triplett <josh@joshtriplett.org> wrote:
> >
> ......
> >
> > As far as I can tell, this will break if the user wants to use
> > ".mybinary" or ".mydir/mybinary" as the name of their init program.
> >
> > For that matter, it would break "...prog" or "...somedir/prog", which
> > would be strange but not something the kernel should prevent.
> >
>
> Wow, seems I didn't give enough thought to it.
>
> > I don't think this code should be attempting to recreate
> > relative-to-absolute filename resolution.
>
> Trust me, I don't want to do it either. However, I need to check if
> ramdisk_execute_command exist before chroot while the cpio is unpacked
> to '/root'.
>
> Maybe I can check it after chroot, but I need to chroot back if it not
> exist. Can I chroot back in a nice way?
>
> I tried to move the mount on '/root' to '/' before I do this check in
> absolute path, but seems '/' is special, the lookup of '/init' never
> follow the mount on '/' and it can't be found. However, if I lookup
> '/../init', it can be found!
>

I have figured it out. While path lookup, '/' won't follow the mount.
However, with the set of LOOKUP_DOWN, it will be followed.

So I will move the mount on '/root' to '/' and check the exist of
ramdisk_execute_command with LOOKUP_DOWN setted.

Seems there is still a long way to go on kernel......

Thanks!
Menglong Dong