[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-man
Subject:    Re: [PATCH] execve.2: document an effect of BINPRM_BUF_SIZE increase to 256
From:       Eugene Syromiatnikov <esyr () redhat ! com>
Date:       2019-03-25 14:12:10
Message-ID: 20190325141205.GQ4231 () asgard ! redhat ! com
[Download RAW message or body]

On Mon, Mar 25, 2019 at 01:22:54PM +0100, Michal Hocko wrote:
> On Fri 22-03-19 01:15:46, Eugene Syromiatnikov wrote:
> > Increase of BINPRM_BUF_SIZE to 256 increases the limit on the possible
> > interpreter line length for scripts to 255.
> > 
> > The relevant kernel commit
> > is 6eb3c3d0a52dca33 ("exec: increase BINPRM_BUF_SIZE to 256").
> 
> It is sad that something as internal as BINPRM_BUF_SIZE is exported to
> the userspace. But aside, why do we have to reflect that change in the
> man page? Sure the value has changed but as long as we really want to
> mention this at all then why not refer to BINPRM_BUF_SIZE rather than
> keep updating man page anytime this changes?

One reason is that man pages document user interface that is not tied to
a specific kernel version, and since there's no easy way to refer to
historical values of the constant, there's a custom to document these
sorts of userspace-impacting UAPI changes, which I've tried to follow.
Mentioning BINPRM_BUF_SIZE is a good idea, though, I'll update the
patch.

Note that there is also another patch pending[1] that attempts (among
other things) to capture kernel's behaviour regarding handling of
oversized interpreter paths, and considering ramifications of changing
BINPRM_BUF_SIZE in that regard, avoiding to document changes of the value
of the constant of the constant seems inexcusable, in my opinion.

[1] https://marc.info/?l=linux-man&m=155321063912237&w=2
[prev in list] [next in list] [prev in thread] [next in thread]