bind commands in ENV file cause spurious warnings by security(8)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

bind commands in ENV file cause spurious warnings by security(8)

Lari Rasku
Oct 27 snapshot, amd64.

I have the following binds in /etc/ksh.bindings:

        bind    '^[[7~'=beginning-of-line
        bind    '^[[8~'=end-of-line
        bind    '^[[2~'=no-op # insert
        bind    '^[[3~'=delete-char-forward

I load the file in /etc/profile by setting the ENV variable:

        export ENV=/etc/ksh.bindings

This causes /usr/libexec/security to spit out the following warnings on
every run:

        /bin/ksh: /etc/ksh.bindings[1]: bind: cannot bind, not a tty
        /bin/ksh: /etc/ksh.bindings[2]: bind: cannot bind, not a tty
        /bin/ksh: /etc/ksh.bindings[3]: bind: cannot bind, not a tty
        /bin/ksh: /etc/ksh.bindings[4]: bind: cannot bind, not a tty

Which earns me pointless daily(8) mail.

The cause seems to be that security(8) tries to run an interactive shell
without a tty, but I expect the devs know better if that's really
necessary, or how it might be worked around.

Reply | Threaded
Open this post in threaded view
|

Re: bind commands in ENV file cause spurious warnings by security(8)

Jeremie Courreges-Anglas-2
On Mon, Oct 30 2017, Lari Rasku <[hidden email]> wrote:

> Oct 27 snapshot, amd64.
>
> I have the following binds in /etc/ksh.bindings:
>
> bind    '^[[7~'=beginning-of-line
> bind    '^[[8~'=end-of-line
> bind    '^[[2~'=no-op # insert
> bind    '^[[3~'=delete-char-forward
>
> I load the file in /etc/profile by setting the ENV variable:
>
> export ENV=/etc/ksh.bindings
>
> This causes /usr/libexec/security to spit out the following warnings on
> every run:
>
> /bin/ksh: /etc/ksh.bindings[1]: bind: cannot bind, not a tty
> /bin/ksh: /etc/ksh.bindings[2]: bind: cannot bind, not a tty
> /bin/ksh: /etc/ksh.bindings[3]: bind: cannot bind, not a tty
> /bin/ksh: /etc/ksh.bindings[4]: bind: cannot bind, not a tty
>
> Which earns me pointless daily(8) mail.
>
> The cause seems to be that security(8) tries to run an interactive shell
> without a tty, but I expect the devs know better if that's really
> necessary,

ENV is checked on purpose.  Whether it should use sh -i is another
question.

> or how it might be worked around.

case $- in *i*) ...;; esac

See /etc/ksh.kshrc.

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply | Threaded
Open this post in threaded view
|

Re: bind commands in ENV file cause spurious warnings by security(8)

Lari Rasku
Jeremie Courreges-Anglas kirjoitti 10/31/17 klo 16:23:
 > On Mon, Oct 30 2017, Lari Rasku <[hidden email]> wrote:
 >> or how it might be worked around.
 >
 > case $- in *i*) ...;; esac
 >
 > See /etc/ksh.kshrc.

Thanks, this spares me some irritation.

 > ENV is checked on purpose.  Whether it should use sh -i is another
 > question.

Having plucked the courage to read the security source - if the goal is
to inspect root's login environment, it would seem more straightforward
to just run `ksh -lic 'echo PATH=$PATH; umask'` than to programmatically
determine the files it sources and then analyze them individually.  But
perhaps it's done this way for a reason.

Another way to "fix" this issue would be just to remove the warnings in
ksh.  Looking at the code, the "cannot bind, not a tty" print is
controlled by a x_tty flag with no other purpose, set unconditionally in
x_init_emacs():

        $ cd /usr/src/bin/ksh; grep -C2 x_tty *.c
        emacs.c-static int     xlp_valid;
        emacs.c-/* end from 4.9 edit.h } */
        emacs.c:static int     x_tty;          /* are we on a tty? */
        emacs.c-static int     x_bind_quiet;   /* be quiet when binding
        keys */
        emacs.c-static int     (*x_last_command)(int);
        --
        emacs.c-       char                    in[LINE + 1];
        emacs.c-
        emacs.c:       if (x_tty == 0) {
        emacs.c-               bi_errorf("cannot bind, not a tty");
        emacs.c-               return (1);
        --
        emacs.c-x_init_emacs(void)
        emacs.c-{
        emacs.c:       x_tty = 1;
        emacs.c-       ainit(AEDIT);
        emacs.c-       x_nextcmd = -1;

Where x_init_emacs() is called through x_init() if the shell is
interactive.  This looks like vestigial code, since the kb_add()s in
x_init_emacs() go through just fine whether a tty is attached or not.

I can prepare a patch for this if desired.

Reply | Threaded
Open this post in threaded view
|

Re: bind commands in ENV file cause spurious warnings by security(8)

Jeremie Courreges-Anglas-2
On Wed, Nov 01 2017, Lari Rasku <[hidden email]> wrote:

> Jeremie Courreges-Anglas kirjoitti 10/31/17 klo 16:23:
>> On Mon, Oct 30 2017, Lari Rasku <[hidden email]> wrote:
>>> or how it might be worked around.
>>
>> case $- in *i*) ...;; esac
>>
>> See /etc/ksh.kshrc.
>
> Thanks, this spares me some irritation.
>
>> ENV is checked on purpose.  Whether it should use sh -i is another
>> question.
>
> Having plucked the courage to read the security source - if the goal is
> to inspect root's login environment, it would seem more straightforward
> to just run `ksh -lic 'echo PATH=$PATH; umask'` than to programmatically
> determine the files it sources and then analyze them individually.  But
> perhaps it's done this way for a reason.
>
> Another way to "fix" this issue would be just to remove the warnings in
> ksh.  Looking at the code, the "cannot bind, not a tty" print is
> controlled by a x_tty flag with no other purpose, set unconditionally in
> x_init_emacs():
>
> $ cd /usr/src/bin/ksh; grep -C2 x_tty *.c
> emacs.c-static int     xlp_valid;
> emacs.c-/* end from 4.9 edit.h } */
> emacs.c:static int     x_tty;          /* are we on a tty? */
> emacs.c-static int     x_bind_quiet;   /* be quiet when binding
> keys */
> emacs.c-static int     (*x_last_command)(int);
> --
> emacs.c-       char                    in[LINE + 1];
> emacs.c-
> emacs.c:       if (x_tty == 0) {
> emacs.c-               bi_errorf("cannot bind, not a tty");
> emacs.c-               return (1);
> --
> emacs.c-x_init_emacs(void)
> emacs.c-{
> emacs.c:       x_tty = 1;
> emacs.c-       ainit(AEDIT);
> emacs.c-       x_nextcmd = -1;
>
> Where x_init_emacs() is called through x_init() if the shell is
> interactive.  This looks like vestigial code, since the kb_add()s in
> x_init_emacs() go through just fine whether a tty is attached or not.
>
> I can prepare a patch for this if desired.

Obviously x_init_emacs does more than than just set x_tty.  For example,
it touches kblist and AEDIT.  While bypassing x_tty may run fine now
because those variables are initialized to zero, I find this
non-obvious and fragile.  Testing x_tty means less questions.

And I think it's reasonable to process keybindings in interactive mode
only.

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply | Threaded
Open this post in threaded view
|

Re: bind commands in ENV file cause spurious warnings by security(8)

Todd C. Miller
On Wed, 01 Nov 2017 14:03:13 +0100, Jeremie Courreges-Anglas wrote:

> Obviously x_init_emacs does more than than just set x_tty.  For example,
> it touches kblist and AEDIT.  While bypassing x_tty may run fine now
> because those variables are initialized to zero, I find this
> non-obvious and fragile.  Testing x_tty means less questions.
>
> And I think it's reasonable to process keybindings in interactive mode
> only.

Right, there's no point in processing keybindings in non-interactive
mode.

 - todd

Reply | Threaded
Open this post in threaded view
|

Re: bind commands in ENV file cause spurious warnings by security(8)

Lari Rasku
In reply to this post by Jeremie Courreges-Anglas-2
Jeremie Courreges-Anglas kirjoitti 11/01/17 klo 15:03:
 > Obviously x_init_emacs does more than than just set x_tty.
I should've been clearer; obviously I didn't mean to call all of
x_init_emacs vestigial code, just the x_tty set-test code path through
it.  But you're right, I was too eager - nixing it is not a good idea.

The proper fix would be for security(8) not to process its files in
incompatible modes, but there I can't contribute much beyond noise.