Mailing List Archive

John R. Graham wrote:
> On the forums, I've seen the question, "Why isn't my .bashrc being
> executed when I log in as root but is being executed when I log in as a
> normal user?," asked half a dozen times on the forums. Heck, I even
> asked it myself a few years ago. Now, two years later, from a slightly
> more mature level of domain knowledge, I have to ask why the root cause
> shouldn't be addressed. Why can't the simple little default
> .bash_profile from /etc/skel be put into /root as well?

When catalyst builds a stage tarball, it doesn't add any additional files. All
files in any stage tarball are created by one of the packages contained within.
In order to do this, a package such as baselayout would have to install the file.

Looking at my local install, it's actually bash that creates
/etc/skel/.bash{rc,_logout,_profile}. You can appeal to the maintainer(s) of the
bash ebuild (should be the base-system herd) to add that functionality, but I
really doubt you'll convince them.

--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Catalyst/Installer + x86 release coordinator
--
gentoo-dev@gentoo.org mailing list

Andrew Gaffney wrote:
> When catalyst builds a stage tarball, it doesn't add any additional
> files. All files in any stage tarball are created by one of the
> packages contained within. In order to do this, a package such as
> baselayout would have to install the file.
>
> Looking at my local install, it's actually bash that creates
> /etc/skel/.bash{rc,_logout,_profile}. You can appeal to the
> maintainer(s) of the bash ebuild (should be the base-system herd) to
> add that functionality, but I really doubt you'll convince them.
I understand. Philosophically, it probably fits better in something
like sys-apps/miscfiles. But where it should or shouldn't come from
doesn't answer the fundamental question, "Shouldn't it be there, from
*some* source?"

- John
--
gentoo-dev@gentoo.org mailing list

John R. Graham wrote:
> like sys-apps/miscfiles. But where it should or shouldn't come from
> doesn't answer the fundamental question, "Shouldn't it be there, from
> *some* source?"
Easy answer: no. Do you really want any script to automatically run
when you login as root? think of exploits and the ability to do
"/bin/echo rm -rf / >> /root/.bash_profile"

It would be nice if one could tell bash to not run any ~/.bash* when
{e,}uid==0.

--
=======================================================
Mike Doty kingtaco -at- gentoo.org
Gentoo Council
Gentoo Infrastructure
Gentoo/AMD64 Strategic Lead
GPG: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05
=======================================================
--
gentoo-dev@gentoo.org mailing list

Mike, that exploit is neither easier nor harder if a default
.bash_profile exists. Or, am I missing something?

- John

Mike Doty wrote:
> John R. Graham wrote:
>> like sys-apps/miscfiles. But where it should or shouldn't come from
>> doesn't answer the fundamental question, "Shouldn't it be there, from
>> *some* source?"
> Easy answer: no. Do you really want any script to automatically run
> when you login as root? think of exploits and the ability to do
> "/bin/echo rm -rf / >> /root/.bash_profile"
>
> It would be nice if one could tell bash to not run any ~/.bash* when
> {e,}uid==0.
>
--
gentoo-dev@gentoo.org mailing list

John R. Graham wrote:
> Why can't the simple little default
> .bash_profile from /etc/skel be put into /root as well?
>

$HOME directories shouldn't be touched by emerge. This is the user's turf.

On Wednesday 19 September 2007, Mike Doty wrote:
> John R. Graham wrote:
> > like sys-apps/miscfiles. But where it should or shouldn't come from
> > doesn't answer the fundamental question, "Shouldn't it be there, from
> > *some* source?"
>
> Easy answer: no. Do you really want any script to automatically run
> when you login as root? think of exploits and the ability to do
> "/bin/echo rm -rf / >> /root/.bash_profile"

coreutils will not `rm -rf /`:
rm: cannot remove root directory `/'

that said, anyone who has write access to /root owns the system ... whether
the file exists by default is irrelevant
-mike

On Wednesday 19 September 2007, Andrew Gaffney wrote:
> John R. Graham wrote:
> > On the forums, I've seen the question, "Why isn't my .bashrc being
> > executed when I log in as root but is being executed when I log in as a
> > normal user?," asked half a dozen times on the forums. Heck, I even
> > asked it myself a few years ago. Now, two years later, from a slightly
> > more mature level of domain knowledge, I have to ask why the root cause
> > shouldn't be addressed. Why can't the simple little default
> > .bash_profile from /etc/skel be put into /root as well?
>
> When catalyst builds a stage tarball, it doesn't add any additional files.
> All files in any stage tarball are created by one of the packages contained
> within. In order to do this, a package such as baselayout would have to
> install the file.
>
> Looking at my local install, it's actually bash that creates
> /etc/skel/.bash{rc,_logout,_profile}. You can appeal to the maintainer(s)
> of the bash ebuild (should be the base-system herd) to add that
> functionality, but I really doubt you'll convince them.

the issue is hardly limited to bash ... by this argument, you propose to have
every package which could possibly install into /etc/skel/ have special case
code to also install into /root/

what catalyst should do is just before cleaning up the stage3 root and packing
it up is run `rsync -a /etc/skel/ /root/`

no, this cannot live in baselayout (the package that creates /root/), because
it cannot be run everytime a user upgrades the baselayout package. no, it
cannot be tied to USE=build (used to make stage1) or USE=bootstrap (use to
make stage2) as the only time the /etc/skel/ -> /root/ sync can sanely happen
is in the final steps of creating a stage3 ... and there is nothing to
differentiate the creation of a stage3 from a normal build, nor is there a
sane way to make sure baselayout is the very last package in the stage3 build
step
-mike

Am Donnerstag, 20. September 2007 schrieb ext Alin Năstac:
> John R. Graham wrote:
> > Why can't the simple little default
> > .bash_profile from /etc/skel be put into /root as well?
>
> $HOME directories shouldn't be touched by emerge.

And especially not root's $HOME.

Bye...

Dirk
--
Dirk Heinrichs | Tel: +49 (0)162 234 3408
Configuration Manager | Fax: +49 (0)211 47068 111
Capgemini Deutschland | Mail: dirk.heinrichs@capgemini.com
Wanheimerstraße 68 | Web: http://www.capgemini.com
D-40468 Düsseldorf | ICQ#: 110037733
GPG Public Key C2E467BB | Keyserver: www.keyserver.net

I didn't say anything about emerge; I was talking about the Stage
tarballs. I know, I know: Catalyst uses emerge.

But, hasn't anyone realized that bash is _broken_ if this file doesn't
exist? Quoting from the upstream-provided man page, "When an
interactive shell that is not a login shell is started, bash reads and
executes commands from ~/.bashrc, if that file exists." Is that really
the intention here? To break upstream-defined behavior?

- John


Alin Năstac wrote:
> John R. Graham wrote:
>
>> Why can't the simple little default
>> .bash_profile from /etc/skel be put into /root as well?
>>
>>
>
> $HOME directories shouldn't be touched by emerge. This is the user's turf.
>
>
--
gentoo-dev@gentoo.org mailing list

John R. Graham wrote:
> I didn't say anything about emerge; I was talking about the Stage
> tarballs. I know, I know: Catalyst uses emerge.
>
> But, hasn't anyone realized that bash is _broken_ if this file doesn't
> exist? Quoting from the upstream-provided man page, "When an
> interactive shell that is not a login shell is started, bash reads and
> executes commands from ~/.bashrc, if that file exists." Is that really
> the intention here? To break upstream-defined behavior?

First, please don't top-post. Second, you have an odd definition of "broken".
You seem to have complete glossed over the last part of the sentence that you
pasted: "if that file exists". Bash will *not* freak out and rape your dog if
the file doesn't exist. All it means is that you get nothing more in your env
than what's defined by /etc/profile.

--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Catalyst/Installer + x86 release coordinator
--
gentoo-dev@gentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John R. Graham wrote:
> But, hasn't anyone realized that bash is _broken_ if this file doesn't
> exist? Quoting from the upstream-provided man page, "When an
> interactive shell that is not a login shell is started, bash reads and
> executes commands from ~/.bashrc, if that file exists." Is that really
> the intention here? To break upstream-defined behavior?

John,
From the section you quoted there, there's absolutely no indication
that a .bashrc file *must* exist, in fact, they even explicitly add the
"if that file exists" to show acceptance of the fact that it might not...
Mike 5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFG8l6bu7rWomwgFXoRAvPwAJ9VFFL6rfLrIgtJw2h7F/WfK9ohwgCdEarz
AtyrRbnXan5cAlCsOL1LL7I=
=k/u0
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

Mike, I agree. But, the file that _must_ exist isn't "~/.bashrc" but
"~/.bash_profile". That's where the that particular bit of
man-page-defined behavior is implemented. If "~/.bash_profile" doesn't
exist, then "~/.bashrc" won't be sourced whether it exists or not.

- John
--
gentoo-dev@gentoo.org mailing list

Andrew. Sorry 'bout the top posting; won't do it again. For the rest,
please see my reply to Mike Auty on the same topic.

- John
--
gentoo-dev@gentoo.org mailing list

"John R. Graham" <n3440d@gmail.com> posted 46F25716.4050608@gmail.com,
excerpted below, on Thu, 20 Sep 2007 07:18:46 -0400:

> But, hasn't anyone realized that bash is _broken_ if this file doesn't
> exist? Quoting from the upstream-provided man page, "When an
> interactive shell that is not a login shell is started, bash reads and
> executes commands from ~/.bashrc, if that file exists." Is that really
> the intention here? To break upstream-defined behavior?

... "if that file exists." IOW, it doesn't /have/ to exist, and for
root, many prefer it /not/ exist.

But in any case, as mentioned by others already, (human user) home dirs
shouldn't be touched by ebuilds (or stages), and /root is exactly that, a
(human user) home dir. Home dirs are the domain of the local users and
(particularly for /root) sysadmins, not distribution packages (or
stages). If the sysadmin wants a /root/.bashrc, it's naturally his
privilege and responsibility to create and maintain it according to his
needs/preferences.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

--
gentoo-dev@gentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John R. Graham wrote:
> Mike, I agree. But, the file that _must_ exist isn't "~/.bashrc" but
> "~/.bash_profile". That's where the that particular bit of
> man-page-defined behavior is implemented. If "~/.bash_profile" doesn't
> exist, then "~/.bashrc" won't be sourced whether it exists or not.

Well, bash can't install a .bash_profile file into every user's home
directory for obvious reasons. That means they shouldn't rely on the
existence of one to source .bashrc, otherwise they could never guarantee
that functionality...

It appears as though you're looking for a location that is guaranteed to
be installed by bash and always executed when there's a non-login shell
start, from where you can source ${HOME}/.bashrc. I'm not familiar
enough with bash or Gentoo's setup of bash to comment on this I'm afraid
(possibly /etc/bash/bashrc?), but relying on .bash_profile so that you
can or can't source ${HOME}/.bashrc seems a little odd.

Moreover, however ${HOME}/.bashrc got into ${HOME}, presumably
.bash_profile could be put there at the same time if it doesn't already
exist?

Mike 5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFG8mcFu7rWomwgFXoRAnIIAKCUC1ShfOYvKKt5SN4oGV1uYz8HkACfVkVU
72TtoVvFFI/RXR4WGy5ya4o=
=dxNr
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

On Wed, 2007-09-19 at 21:57 -0400, John R. Graham wrote:
> Why can't the simple little default
> .bash_profile from /etc/skel be put into /root as well

/etc/skel is for users created by the add user commands.
root is inherently added *before* bash is installed, thus
doesn't get anything from skel.
Also, don't assume that the root user uses the bash shell.

Thanks

Roy

--
gentoo-dev@gentoo.org mailing list

On Thu, 20 Sep 2007 08:09:08 -0400 "John R. Graham" <n3440d@gmail.com>
wrote:
> Mike, I agree. But, the file that _must_ exist isn't "~/.bashrc" but
> "~/.bash_profile".

That's wrong. Quote:

"When bash is invoked as an interactive login shell, or as a non-inter-
active shell with the --login option, it first reads and executes com-
mands from the file /etc/profile, if that file exists. After reading
that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile,
in that order, and reads and executes commands from the first one that
exists and is readable. The --noprofile option may be used when the
shell is started to inhibit this behavior."

Notice "the first one that exists and is readable".

> If "~/.bash_profile" doesn't exist, then "~/.bashrc" won't be sourced
> whether it exists or not.

Wrong again. Two paragraphs down in the man page:

"When an interactive shell that is not a login shell is started, bash
reads and executes commands from ~/.bashrc, if that file exists."

In this case ~/.bashrc is sourced directly.


Cheers,
Renat

--
Probleme kann man niemals mit derselben Denkweise loesen,
durch die sie entstanden sind.
(Einstein)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You could add '[ -n "${BASH}" -a -f ~/.bashrc ] && . ~/.bashrc' to /etc/profile.d/bash.sh. This file could be installed by app-shells/bash.

- --
Arfrever Frehtes Taifersar Arahesis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFG8mo1/axNJ4Xo/ZERAlTaAJ9KBBMZ5iC54va2Ajco/ezyRVipXwCgkneB
IGDioZ83MCaASlWxO9JdnnI=
=psDE
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

On Thu, 2007-09-20 at 03:03 -0400, Mike Frysinger wrote:
> what catalyst should do is just before cleaning up the stage3 root and packing
> it up is run `rsync -a /etc/skel/ /root/`

It definitely should not. One of my primary motivations with catalyst
is to ensure that the users get *exactly* what would be provided by the
profiles/packages. We don't add extra files into the stages and likely
never will. Doing something like this in catalyst would create an
inconsistency between doing a stage3 install and any previous stage
installs. Yes, we don't support stage1 anymore, but we still support
stage1 users once their systems are up and running. Having them
inconsistent only causes one more area where we have to do extra
troubleshooting to determine the cause.

> no, this cannot live in baselayout (the package that creates /root/), because
> it cannot be run everytime a user upgrades the baselayout package. no, it
> cannot be tied to USE=build (used to make stage1) or USE=bootstrap (use to
> make stage2) as the only time the /etc/skel/ -> /root/ sync can sanely happen
> is in the final steps of creating a stage3 ... and there is nothing to
> differentiate the creation of a stage3 from a normal build, nor is there a
> sane way to make sure baselayout is the very last package in the stage3 build
> step

Well, it depends on whether we're interested in getting all of /etc/skel
or just the .bash* files. About the only thing I would see useful as
"defaults" is the .bash* stuff and a .ssh directory. I do agree that
everything else should be left up to the user. If we decided what to
include and limited it, it shouldn't be a problem to do it via USE=build
at all.

Of course, that doesn't answer the question, "Do we want to?"

I have no clue.

--
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

On Thu, 2007-09-20 at 12:21 +0000, Duncan wrote:
> But in any case, as mentioned by others already, (human user) home dirs
> shouldn't be touched by ebuilds (or stages), and /root is exactly that, a
> (human user) home dir. Home dirs are the domain of the local users and
> (particularly for /root) sysadmins, not distribution packages (or
> stages). If the sysadmin wants a /root/.bashrc, it's naturally his
> privilege and responsibility to create and maintain it according to his
> needs/preferences.

While I would normally agree, there's nothing wrong with having sensible
defaults. After all, we install a bunch of stuff into /home/$user
thanks to /etc/skel, so how is this different?

--
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

On Thu, 2007-09-20 at 13:29 +0100, Roy Marples wrote:
> Also, don't assume that the root user uses the bash shell.

The root user does *default* to the bash shell on Linux, at least.

Of course, we could do whatever is appropriate for other targets.

--
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

On Thursday 20 September 2007, Chris Gianelloni wrote:
> On Thu, 2007-09-20 at 03:03 -0400, Mike Frysinger wrote:
> > what catalyst should do is just before cleaning up the stage3 root and
> > packing it up is run `rsync -a /etc/skel/ /root/`
>
> It definitely should not. One of my primary motivations with catalyst
> is to ensure that the users get *exactly* what would be provided by the
> profiles/packages. We don't add extra files into the stages and likely
> never will. Doing something like this in catalyst would create an
> inconsistency between doing a stage3 install and any previous stage
> installs. Yes, we don't support stage1 anymore, but we still support
> stage1 users once their systems are up and running. Having them
> inconsistent only causes one more area where we have to do extra
> troubleshooting to determine the cause.

not really ... someone installing by hand and someone taking a default setup
are different things. we know that someone taking a stage3 has never
configured anything before and so we can safely put defaults into /root/. we
have no idea what people have done when they run emerge themselves. that is
why only putting this into catalyst makes sense.

> > no, this cannot live in baselayout (the package that creates /root/),
> > because it cannot be run everytime a user upgrades the baselayout
> > package. no, it cannot be tied to USE=build (used to make stage1) or
> > USE=bootstrap (use to make stage2) as the only time the /etc/skel/ ->
> > /root/ sync can sanely happen is in the final steps of creating a stage3
> > ... and there is nothing to differentiate the creation of a stage3 from a
> > normal build, nor is there a sane way to make sure baselayout is the very
> > last package in the stage3 build step
>
> Well, it depends on whether we're interested in getting all of /etc/skel
> or just the .bash* files. About the only thing I would see useful as
> "defaults" is the .bash* stuff and a .ssh directory. I do agree that
> everything else should be left up to the user. If we decided what to
> include and limited it, it shouldn't be a problem to do it via USE=build
> at all.

anything that is part of the system /etc/skel/ makes sense (iow, anything that
is in /etc/skel/ at the end of stage3). the files from bash and the .ssh dir
are the only things that go into /etc/skel/ right now for the default system.
-mike

Chris Gianelloni <wolf31o2@gentoo.org> posted
1190305172.8728.19.camel@inertia.twi-31o2.org, excerpted below, on Thu,
20 Sep 2007 09:19:31 -0700:

> While I would normally agree, there's nothing wrong with having sensible
> defaults. After all, we install a bunch of stuff into /home/$user
> thanks to /etc/skel, so how is this different?

The big distinction (other than the privilege one) IMO is that putting
things into /etc/skel isn't directly inserting them into a "live" user's
home dir. There's a level of indirection, such that "live" users don't
have their "live" environments interfered with, and such that there's a
chance for the admin to review things if desired, before actually acting
on anything in skel in terms of setting up a new user.

IOW, a direct comparison would be if we setup something like
/etc/rootskel/. Of course, that's not quite a correct parallel either,
since it's not often that a new "root" user appears =8^P, but the point
I'm trying to make by drawing the parallel should be obvious.

Matter of fact, I'd rather /etc/profile was handled a bit more indirectly
as well, say treating it much like /etc/make.conf, creating
make.conf.example if the file already existed, or like the /usr/share/
baselayout/* files, as I handle the system profile rather differently
here too, but that's a somewhat different argument as it's existing
behavior (to some extent addressed with etc-update, but one could say so
was fstab). At least we can avoid creating further problems of the sort
we're avoiding with the above *.example and baselayout/* cases, however,
as the current proposal would IMO do.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

--
gentoo-dev@gentoo.org mailing list

On Thu, 2007-09-20 at 12:34 -0400, Mike Frysinger wrote:
> > > what catalyst should do is just before cleaning up the stage3 root and
> > > packing it up is run `rsync -a /etc/skel/ /root/`
> >
> > It definitely should not. One of my primary motivations with catalyst
> > is to ensure that the users get *exactly* what would be provided by the
> > profiles/packages. We don't add extra files into the stages and likely
> > never will. Doing something like this in catalyst would create an
> > inconsistency between doing a stage3 install and any previous stage
> > installs. Yes, we don't support stage1 anymore, but we still support
> > stage1 users once their systems are up and running. Having them
> > inconsistent only causes one more area where we have to do extra
> > troubleshooting to determine the cause.
>
> not really ... someone installing by hand and someone taking a default setup
> are different things. we know that someone taking a stage3 has never
> configured anything before and so we can safely put defaults into /root/. we
> have no idea what people have done when they run emerge themselves. that is
> why only putting this into catalyst makes sense.

I'll respectfully disagree and say again that I won't add anything like
this to catalyst for the reasons mentioned above. I see no reason why
we cannot provide sensible defaults in stages lower than three,
especially since I want to see everything in ebuild code.

Also, my plan for this would be add the copying of the .bash* files
from /etc/skel if and only if USE=build *and* the files do not already
exist, done during pkg_preinst/pkg_postinst somewhere. This will pull
it into the stage1 tarball, making it available to everyone on all
further stages, it keeps it from being done every time someone emerges
bash, it doesn't stomp on existing files, and it doesn't show up in VDB
linked to the bash package. Is this acceptable?

> > Well, it depends on whether we're interested in getting all of /etc/skel
> > or just the .bash* files. About the only thing I would see useful as
> > "defaults" is the .bash* stuff and a .ssh directory. I do agree that
> > everything else should be left up to the user. If we decided what to
> > include and limited it, it shouldn't be a problem to do it via USE=build
> > at all.
>
> anything that is part of the system /etc/skel/ makes sense (iow, anything that
> is in /etc/skel/ at the end of stage3). the files from bash and the .ssh dir
> are the only things that go into /etc/skel/ right now for the default system.

OK. So we now know that only bash/openssh would be really important
here, and the .ssh directory really isn't much of a show-stopper, since
it isn't populated. I mention this only because we don't install
openssh until stage3, so there's no special USE flags in use at that
time. If we limited it to bash (and tcsh, etc. for non-Linux) using
USE=build, it would satisfy this request, one which I personally would
like to see done, and still not have to change a single line of code in
catalyst, which also respects my wishes. It doesn't stomp on user's
files. All in all, it seems like a safe enough solution to me.

--
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation