Use of --rcfile does not preclude read of /etc/bash.bashrc

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

Use of --rcfile does not preclude read of /etc/bash.bashrc

Nat!
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib 
-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-fdebug-prefix-map=/build/bash-IrsGKQ/bash-4.4=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall -no-pie
-Wno-parentheses -Wno-format-security
uname output: Linux terodde 4.13.0-21-generic #24-Ubuntu SMP Mon Dec 18
17:29:16 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.4
Patch Level: 12
Release Status: release

Description:
     The documentation states, that /etc/bash.bashrc should not be read
(rightfully so IMO) with
     --rcfile.

        --rcfile file
               Execute  commands  from file instead of the system wide
initialization file /etc/bash.bashrc and the
               standard personal initialization file ~/.bashrc if the
shell is interactive (see INVOCATION below).

     Yet it does and it pollutes my values.

Repeat-By:
nat@terodde:/tmp$     echo 'echo $PS1' > x.sh
nat@terodde:/tmp$     echo 'exit' >> x.sh
nat@terodde:/tmp$     PS1='>>>' strace -o trace bash --noprofile
--rcfile x.sh
${debian_chroot:+($debian_chroot)}\u@\h:\w\$
nat@terodde:/tmp$ grep bashrc trace
openat(AT_FDCWD, "/etc/bash.bashrc", O_RDONLY) = 3
read(3, "# System-wide .bashrc file for i"..., 2188) = 2188

Ciao

    Nat!



Reply | Threaded
Open this post in threaded view
|

Re: Use of --rcfile does not preclude read of /etc/bash.bashrc

Eduardo A. Bustamante López
On Tue, Jan 2, 2018 at 3:05 PM, Nat! <[hidden email]> wrote:
[...]
> Description:
>     The documentation states, that /etc/bash.bashrc should not be read
> (rightfully so IMO) with
>     --rcfile.

FWIW, there are two things going on here:

(1) /etc/bash.bashrc is actually disabled by default in the upstream
bash source code distribution and it's not documented:

$ grep SYS_BASHRC config-top.h
/* #define SYS_BASHRC "/etc/bash.bashrc" */

(2) The behavior you observe (SYS_BASHRC and bashrc_file both being
sourced) has been in place for a few years now (since bash 2.05 at
least), so I don't think it's a good idea to change this now in
upstream code, given that it'll potentially affect users that rely on
this to behave in a certain way for distros that enable SYS_BASHRC.

$ git blame shell.c | sed -n '1187,1198p'
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 +0000 1187)       /* bash */
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 +0000 1188)       if
(act_like_sh == 0 && no_rc == 0)
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 +0000 1189) {
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 +0000 1190) #ifdef SYS_BASHRC
b72432fdc (Jari Aalto 1999-02-19 17:11:39 +0000 1191) #  if defined (__OPENNT)
b72432fdc (Jari Aalto 1999-02-19 17:11:39 +0000 1192)
maybe_execute_file (_prefixInstallPath(SYS_BASHRC, NULL, 0), 1);
b72432fdc (Jari Aalto 1999-02-19 17:11:39 +0000 1193) #  else
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 +0000 1194)
maybe_execute_file (SYS_BASHRC, 1);
bb70624e9 (Jari Aalto 2000-03-17 21:46:59 +0000 1195) #  endif
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 +0000 1196) #endif
28ef6c316 (Jari Aalto 2001-04-06 19:14:31 +0000 1197)
maybe_execute_file (bashrc_file, 1);
^726f6388 (Jari Aalto 1996-08-26 18:22:31 +0000 1198) }

As you can see, the wording that you report is not present in the
upstream distribution, so this is likely a debian patch.

$ PAGER= man doc/bash.1 | grep -e '^[[:space:]]*--rcfile file' -A3
       --rcfile file
              Execute  commands  from file instead of the standard
personal initialization file ~/.bashrc if the shell is interac‐
              tive (see INVOCATION below).


IMO, the right thing to do here would be to ask the Debian package
maintainer to correct the wording to indicate that both
/etc/bash.bashrc AND the file provided by --bashrc are executed.
Important to note here also that SYS_BASHRC is a mechanism exposed for
sysadmins who want to ensure that a certain configuration is applied
system-wide, regardless of what the users of the system desire. If
it's a system you control, you can always re-compile bash or remove
the file.

See: https://lists.gnu.org/archive/html/bug-bash/2009-05/msg00035.html
and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516152 for prior
discussion.

Reply | Threaded
Open this post in threaded view
|

Re: Use of --rcfile does not preclude read of /etc/bash.bashrc

Nat!
I tried to come up with a workaround, but I couldn't find any.

Basically what I do:

     env -i bash --norc --noprofile


This gives me an interactive shell, with a very clean environment (even
no PATH), that does not contain system specify "surprises".
This works.

But what I really want is to set up a custom environment before going
interactive.

     env -i bash --norc --noprofile --rcfile custom.sh

This doesn't work, because --norc (IMO) incorrectly preempts the
--rcfile use, where's the point ?

The command

     env -i bash --noprofile --rcfile x.sh

does work to my satisfactions on systems, that do not enable SYS_BASHRC
(OS X).

So if --rcfile was a feature earlier than SYS_BASHRC (2.05), it's a bona
fide regression.

Ciao

    Nat!



On 03.01.2018 02:39, Eduardo Bustamante wrote:

> On Tue, Jan 2, 2018 at 3:05 PM, Nat! <[hidden email]> wrote:
> [...]
>> Description:
>>      The documentation states, that /etc/bash.bashrc should not be read
>> (rightfully so IMO) with
>>      --rcfile.
> FWIW, there are two things going on here:
>
> (1) /etc/bash.bashrc is actually disabled by default in the upstream
> bash source code distribution and it's not documented:
>
> $ grep SYS_BASHRC config-top.h
> /* #define SYS_BASHRC "/etc/bash.bashrc" */
>
> (2) The behavior you observe (SYS_BASHRC and bashrc_file both being
> sourced) has been in place for a few years now (since bash 2.05 at
> least), so I don't think it's a good idea to change this now in
> upstream code, given that it'll potentially affect users that rely on
> this to behave in a certain way for distros that enable SYS_BASHRC.
>
> $ git blame shell.c | sed -n '1187,1198p'
> ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 +0000 1187)       /* bash */
> ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 +0000 1188)       if
> (act_like_sh == 0 && no_rc == 0)
> ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 +0000 1189) {
> ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 +0000 1190) #ifdef SYS_BASHRC
> b72432fdc (Jari Aalto 1999-02-19 17:11:39 +0000 1191) #  if defined (__OPENNT)
> b72432fdc (Jari Aalto 1999-02-19 17:11:39 +0000 1192)
> maybe_execute_file (_prefixInstallPath(SYS_BASHRC, NULL, 0), 1);
> b72432fdc (Jari Aalto 1999-02-19 17:11:39 +0000 1193) #  else
> ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 +0000 1194)
> maybe_execute_file (SYS_BASHRC, 1);
> bb70624e9 (Jari Aalto 2000-03-17 21:46:59 +0000 1195) #  endif
> ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 +0000 1196) #endif
> 28ef6c316 (Jari Aalto 2001-04-06 19:14:31 +0000 1197)
> maybe_execute_file (bashrc_file, 1);
> ^726f6388 (Jari Aalto 1996-08-26 18:22:31 +0000 1198) }
>
> As you can see, the wording that you report is not present in the
> upstream distribution, so this is likely a debian patch.
>
> $ PAGER= man doc/bash.1 | grep -e '^[[:space:]]*--rcfile file' -A3
>         --rcfile file
>                Execute  commands  from file instead of the standard
> personal initialization file ~/.bashrc if the shell is interac‐
>                tive (see INVOCATION below).
>
>
> IMO, the right thing to do here would be to ask the Debian package
> maintainer to correct the wording to indicate that both
> /etc/bash.bashrc AND the file provided by --bashrc are executed.
> Important to note here also that SYS_BASHRC is a mechanism exposed for
> sysadmins who want to ensure that a certain configuration is applied
> system-wide, regardless of what the users of the system desire. If
> it's a system you control, you can always re-compile bash or remove
> the file.
>
> See: https://lists.gnu.org/archive/html/bug-bash/2009-05/msg00035.html
> and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516152 for prior
> discussion.
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Use of --rcfile does not preclude read of /etc/bash.bashrc

Chet Ramey
On 1/6/18 8:14 AM, Nat! wrote:

> I tried to come up with a workaround, but I couldn't find any.
>
> Basically what I do:
>
>     env -i bash --norc --noprofile
>
>
> This gives me an interactive shell, with a very clean environment (even no
> PATH), that does not contain system specify "surprises".
> This works.
>
> But what I really want is to set up a custom environment before going
> interactive.
>
>     env -i bash --norc --noprofile --rcfile custom.sh
>
> This doesn't work, because --norc (IMO) incorrectly preempts the --rcfile
> use, where's the point ?

It's not incorrect; --norc is intended to suppress execution of the
interactive shell startup files, even if you specify another file to not
execute.

You could use $ENV, but that's only effective for shells started in
Posix mode.

>
> The command
>
>     env -i bash --noprofile --rcfile x.sh
>
> does work to my satisfactions on systems, that do not enable SYS_BASHRC (OS
> X).
>
> So if --rcfile was a feature earlier than SYS_BASHRC (2.05), it's a bona
> fide regression.

It's not a regression. The sole intent of SYS_BASHRC was to allow system
administrators who wanted a file sourced before the user's interactive
shell startup file (e.g., to make sure that some environment variables were
set) to specify one. It's not intended to be overridden, and it's executed
under the same circumstances as the user's bashrc file.

(SYS_BASHRC was inserted in August, 1995 and made its first public
appearance in bash-2.0. Discussion started a few months prior.)

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [hidden email]    http://tiswww.cwru.edu/~chet/

Reply | Threaded
Open this post in threaded view
|

Re: Use of --rcfile does not preclude read of /etc/bash.bashrc

Nat!
Chet Ramey schrieb:
> On 1/6/18 8:14 AM, Nat! wrote:
>
> It's not incorrect; --norc is intended to suppress execution of the
> interactive shell startup files, even if you specify another file to not
> execute.

Without any warning ? The man of the --norc option specifies exactly
which files it is not reading. It's clearly not saying anything about
ignoring the user specified --init-file.

You have to infer this indirectly, thinking how bash probably does it:

```
init_file=${init_file:-~/.bashrc}
if [ -z ${norc} ]
    . ${SYS_BASHRC}
    . ${init_file}
fi
```

when it could (and should IMO) do

```
if [ -z ${norc} ]
    . ${SYS_BASHRC}
    . ${init_file:-~/.bashrc}
else
    if [ ! -z ${init_file} ]
    then
       . ${init_file}
    fi
fi
```

>
> You could use $ENV, but that's only effective for shells started in
> Posix mode.
>
>> The command
>>
>>      env -i bash --noprofile --rcfile x.sh
>>
>> does work to my satisfactions on systems, that do not enable SYS_BASHRC (OS
>> X).
>>
>> So if --rcfile was a feature earlier than SYS_BASHRC (2.05), it's a bona
>> fide regression.
>
> It's not a regression.

As I understand it, w/o SYS_BASHRC the combination of --noprofile
--rcfile suppresses all "code injection" from initfiles into the bash
shell. I would argue that is the intention of someone using --rcfile.

If someone goes to the trouble of typing "bash --rcfile" he surely is
not "logging in" or connecting via "ssh", something that's under the
intent of an administrator. It's a user/developer trying to set up a
custom environment. SYS_BASHRC negates that. So it is a functional
regression from that point on.

  The sole intent of SYS_BASHRC was to allow system
> administrators who wanted a file sourced before the user's interactive
> shell startup file (e.g., to make sure that some environment variables were
> set) to specify one. It's not intended to be overridden, and it's executed
> under the same circumstances as the user's bashrc file.

I would guess, due to the funky ways the bash sources various differing
files during session login and ssh, the main reason for SYS_BASHRC was
to have a single point of modification for people logging into the system.

Or were admins really worried about people using --rcfile and missing
out on their valuable environment variables ? And why would that be more
important than the user choice ?

SYS_BASHRC narrows the use of bash from being a viable (interactive)
language interpreter to just being a login shell. Not everyone is an
admin or user, some people are developers too, especially on debian :)

I found a few predecessors to my query, so I am not the only one and it
is clearly negating user intent:

https://savannah.gnu.org/support/?107950
https://lists.gnu.org/archive/html/bug-bash/2009-05/msg00035.html

>
> (SYS_BASHRC was inserted in August, 1995 and made its first public
> appearance in bash-2.0. Discussion started a few months prior.)
>

It would be interesting to read that discussion. Is it archived somewhere ?

Ciao
    Nat!

Reply | Threaded
Open this post in threaded view
|

Re: Use of --rcfile does not preclude read of /etc/bash.bashrc

Chet Ramey
On 1/9/18 6:19 PM, Nat! wrote:

> Chet Ramey schrieb:
>> On 1/6/18 8:14 AM, Nat! wrote:
>>
>> It's not incorrect; --norc is intended to suppress execution of the
>> interactive shell startup files, even if you specify another file to not
>> execute.
>
> Without any warning ? The man of the --norc option specifies exactly which
> files it is not reading. It's clearly not saying anything about ignoring
> the user specified --init-file.

That's how it's always worked. From the earliest days of the feature -- and
I'm talking even before the 0.98-0.99 days in 1989 -- the --norc option
inhibited sourcing the per-user interactive shell startup file. If the user
wanted to specify a different file, that was the file the shell didn't
source. The --rcfile says which file you want to execute, the --norc option
says you don't want to execute it. This doesn't have anything to do with
SYS_BASHRC.

If you want to talk about improving the documentation, which has said just
about the same thing since 1991 or so, we can do that. Inserting the words
"or the file supplied as an argument to the --rcfile option" would suffice.


> when it could (and should IMO) do
>
> ```
> if [ -z ${norc} ]
>    . ${SYS_BASHRC}
>    . ${init_file:-~/.bashrc}
> else
>    if [ ! -z ${init_file} ]
>    then
>       . ${init_file}
>    fi
> fi
> ```

Yeah, it's literally never done that.

>>> So if --rcfile was a feature earlier than SYS_BASHRC (2.05), it's a bona
>>> fide regression.
>>
>> It's not a regression.
>
> As I understand it, w/o SYS_BASHRC the combination of --noprofile --rcfile
> suppresses all "code injection" from initfiles into the bash shell. I would
> argue that is the intention of someone using --rcfile.

No. The combination of --noprofile --norc suppresses all such "code injection".

>
> If someone goes to the trouble of typing "bash --rcfile" he surely is not
> "logging in" or connecting via "ssh", something that's under the intent of
> an administrator. It's a user/developer trying to set up a custom
> environment. SYS_BASHRC negates that. So it is a functional regression from
> that point on.

Since that's not the point of SYS_BASHRC, this doesn't make much sense.
The personal initialization file, whatever its name, is sourced after
SYS_BASHRC, so there's nothing preventing a developer from setting up a
custom environment and overriding everything he doesn't like in SYS_BASHRC.

>
>  The sole intent of SYS_BASHRC was to allow system
>> administrators who wanted a file sourced before the user's interactive
>> shell startup file (e.g., to make sure that some environment variables were
>> set) to specify one. It's not intended to be overridden, and it's executed
>> under the same circumstances as the user's bashrc file.
>
> I would guess, due to the funky ways the bash sources various differing
> files during session login and ssh, the main reason for SYS_BASHRC was to
> have a single point of modification for people logging into the system.

No. There was already a way to do that: /etc/profile. The point of
SYS_BASHRC was to provide comparable functionality for interactive shells.

> Or were admins really worried about people using --rcfile and missing out
> on their valuable environment variables ? And why would that be more
> important than the user choice ?

Yes, that's what system administrators were worried about, especially in an
environment with shared home directories and users logging into different
machines running different versions of Unix.

As to user choice, that's why it's not enabled by default. Like many
other things, it becomes the system admin's choice.

>
> SYS_BASHRC narrows the use of bash from being a viable (interactive)
> language interpreter to just being a login shell.

That's a little over-dramatic.


> Not everyone is an admin
> or user, some people are developers too, especially on debian :)

If you are a developer, you should be able to build a version of bash that
suits your needs.

>
> I found a few predecessors to my query, so I am not the only one and it is
> clearly negating user intent:
>
> https://savannah.gnu.org/support/?107950
> https://lists.gnu.org/archive/html/bug-bash/2009-05/msg00035.html

If you do not like SYS_BASHRC, you may find it useful to open a bug report
with Debian and ask about their rationale for enabling it in their build.

>> (SYS_BASHRC was inserted in August, 1995 and made its first public
>> appearance in bash-2.0. Discussion started a few months prior.)
>>
>
> It would be interesting to read that discussion. Is it archived somewhere ?

I don't know. I don't think the bug-bash archives go back that far.

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [hidden email]    http://tiswww.cwru.edu/~chet/