bash prompt

[Bill McCormick]

I want to make sure that a system has the same prompt for all users, and
that no matter how a user edits his start up, the prompt will always
contain some portion of the FQDN.

What is the simplest way to accomplish this?

Thanks,

Bill

[Aragorn]

On Wednesday 20 February 2013 16:44, Bill McCormick conveyed the
following to alt.os.linux.debian...

System-wide declaration of "the command prompt" - or in proper UNIX
terminology, the $PS1 variable - is typically done in via /etc/bashrc,
albeit that I was informed that Debian may be using an alternative
configuration file for this, such as /etc/bash.bashrc or something
similar.

However, setting the $PS1 variable there is system-wide only in the
sense that it defines what the command prompt will look like in the base
environment when the user logs in, and as such, any user could always
override this base configuration by editing or reconfiguring his
environment through the usual suspects, i.e. ~/.bashrc and/or
~/.bash_profile.

The only way I see by which you could prohibit a user from modifying his
or her ~/.bashrc and ~/.bash_profile - provided that we're even talking
of GNU Bash as the shell, because there are different types of UNIX
shells and they all have their own configuration files - would be to set
those files up as owned by the root user. To this end, you would have
to chown the files after the user account has been created, because upon
the creation of a user account and its home directory, the home
directory will be populated with copies of everything under /etc/skel
(which is entirely root-owned), and those copies are then chown'ed by
the system to said user account.

Lastly, even the above method is not waterproof, because even though
root may own the files (and have them set up without write permission
for the user), the user's home directory itself is owned by the user and
is writable to said user, so the user still has the permission to delete
those root-owned configuration files and replace them by newly created
copies which are owned by him/her.

To put a long story short, I do not think that there's any way you can
forcefully have the FQDN (or anything else) in the $PS1 without that the
user somehow has an option of overriding that in his own user account.

--
= Aragorn =
(registered GNU/Linux user #223157)

[Richard Kettlewell]

By technical means: modify the shell (fairly easy) and somehow prevent
your users running other shells without petty restrictions (hard,
without reducing the usefulness of the system).

By non-technical means: management diktat. Has the advantage that the
users can ignore it.

--
http://www.greenend.org.uk/rjk/

[Bill McCormick]

Since I'll be doing this repetitively on relatively clean systems, I
think the best option is to make the change to /etc/bash.bashrc and
/etc/skel/.bashrc. I think that should cover the root user and any new
users created.

One thing I was trying to do is bash script the change by doing
something like this:

$ cat /etc/skel/.bashrc| sed 's/\\h/$(hostname -f|sed
's/\.service\.fibertech\.local//')/' > /etc/skel/.bashrc

But that doesn't work. I'm not much of a sed mavan, or even a bash
scripting mavan for that matter.

Any ideas?

Thanks,

Bill

[Kees Theunissen]

Aragorn wrote:

> The only way I see by which you could prohibit a user from modifying his
> or her ~/.bashrc and ~/.bash_profile - provided that we're even talking
> of GNU Bash as the shell, because there are different types of UNIX
> shells and they all have their own configuration files - would be to set
> those files up as owned by the root user. To this end, you would have
> to chown the files after the user account has been created, because upon
> the creation of a user account and its home directory, the home
> directory will be populated with copies of everything under /etc/skel
> (which is entirely root-owned), and those copies are then chown'ed by
> the system to said user account.

Root could as a last step use
chattr +i filename
to make those files immutable.

Once a root-owned file has been made immutable a normal user
can't delete (rm), rename (mv) or change the location (also mv)
of the file. Even root will not be allowed to change anything
but remove the immutable attribute bit.

But even in that case can a user change her prompt by simply
typing something like:
PS1="My new prompt! > "

Regards,

Kees.

--
Kees Theunissen.

[Aragorn]

On Wednesday 20 February 2013 20:37, Kees Theunissen conveyed the
following to alt.os.linux.debian...

> Aragorn wrote:
>
>> The only way I see by which you could prohibit a user from modifying
>> his or her ~/.bashrc and ~/.bash_profile - provided that we're even
>> talking of GNU Bash as the shell, because there are different types
>> of UNIX shells and they all have their own configuration files -
>> would be to set those files up as owned by the root user. To this
>> end, you would have to chown the files after the user account has
>> been created, because upon the creation of a user account and its
>> home directory, the home directory will be populated with copies of
>> everything under /etc/skel (which is entirely root-owned), and those
>> copies are then chown'ed by the system to said user account.
>
> Root could as a last step use
> chattr +i filename
> to make those files immutable.
>
> Once a root-owned file has been made immutable a normal user
> can't delete (rm), rename (mv) or change the location (also mv)
> of the file. Even root will not be allowed to change anything
> but remove the immutable attribute bit.

True. I hadn't thought of that. Likewise, the root user could also
implement an ACL entry for the files - in which case, as with the chattr
approach, root could even lock him-/herself out, apart from unsetting
the ACL security again - but it does also not preclude what you continue
to write here-below...

> But even in that case can a user change her prompt by simply
> typing something like:
> PS1="My new prompt! > "

Ultimately, yes. So that brings us back to square one, which is that
there is no permanent way of preventing the user from changing his or
her $PS1. ;-)

[Richard Kettlewell]

Bill McCormick <wpmcc...@gmail.com> writes:
> Richard Kettlewell wrote:
>> Bill McCormick<wpmcc...@gmail.com> writes:

>>> I want to make sure that a system has the same prompt for all users,
>>> and that no matter how a user edits his start up, the prompt will
>>> always contain some portion of the FQDN.
>>>
>>> What is the simplest way to accomplish this?
>>
>> By technical means: modify the shell (fairly easy) and somehow prevent
>> your users running other shells without petty restrictions (hard,
>> without reducing the usefulness of the system).
>>
>> By non-technical means: management diktat. Has the advantage that the
>> users can ignore it.
>
> Since I'll be doing this repetitively on relatively clean systems, I
> think the best option is to make the change to /etc/bash.bashrc and
> /etc/skel/.bashrc. I think that should cover the root user and any new
> users created.

That doesn’t satisfy the “no matter how a user edits his[sic] start up”
part of the requirement.

> One thing I was trying to do is bash script the change by doing
> something like this:
>
> $ cat /etc/skel/.bashrc| sed 's/\\h/$(hostname -f|sed
> s/\.service\.fibertech\.local//')/' > /etc/skel/.bashrc
>
> But that doesn't work. I'm not much of a sed mavan, or even a bash
> scripting mavan for that matter.

\h already expands to the nodename in a prompt; there’s no point sedding
it out.

--
http://www.greenend.org.uk/rjk/

[Aragorn]

On Wednesday 20 February 2013 20:01, Bill McCormick conveyed the
following to alt.os.linux.debian...

> On 2/20/2013 10:47 AM, Richard Kettlewell wrote:
>
>> Bill McCormick<wpmcc...@gmail.com> writes:
>>
>>> I want to make sure that a system has the same prompt for all users,
>>> and that no matter how a user edits his start up, the prompt will
>>> always contain some portion of the FQDN.
>>>
>>> What is the simplest way to accomplish this?
>>
>> By technical means: modify the shell (fairly easy) and somehow
>> prevent your users running other shells without petty restrictions
>> (hard, without reducing the usefulness of the system).
>>
>> By non-technical means: management diktat. Has the advantage that
>> the users can ignore it.
>>
> Since I'll be doing this repetitively on relatively clean systems, I
> think the best option is to make the change to /etc/bash.bashrc and
> /etc/skel/.bashrc. I think that should cover the root user and any new
> users created.

Yes, but, again, only insofar as the user his-/herself does not change
their $PS1. Duplicating it in /etc/skel/.bashrc isn't going to change
the fact that the user can always edit that file - unless you do things
like "chattr +i" (on the local copy of the file in the user's home
directory) and/or set up an ACL.

> One thing I was trying to do is bash script the change by doing
> something like this:
>
> $ cat /etc/skel/.bashrc| sed 's/\\h/$(hostname -f|sed
> 's/\.service\.fibertech\.local//')/' > /etc/skel/.bashrc

For starters, there's no need to do that because - as Richard Kettlewell
said - the "\n" already covers the hostname. Secondly, see below...

> But that doesn't work. I'm not much of a sed mavan, or even a bash
> scripting mavan for that matter.

First of all, that's what we call UUOC ("useless use of cat"), but more
importantly, you are truncating the file (by way of your redirect)
before you are actually processing its contents with sed, so naturally,
that wouldn't work. If you're going to modify an existing file with sed
and you want to keep the modifications on disk, you will need to make
use of an intermediary step via a temporary file.

But, as stated already, the whole exercise of editing the file via sed
is pointless because a Bourne-compatible UNIX shell already has a series
of built-in tokens which can be used to represent the hostname -
abridged or the complete FQDN - and other values in the $PS1 variable.

Either way, whatever you do, you will never be able to prevent the user
from modifying their $PS1, even if the user has to do it manually each
time they log in. So perhaps it would be advisable if you told us why
exactly you want to go about and do this. It is possible that your
whole thought process of preventing the modification of the user's $PS1
is only one way of accomplishing that which you really want.

[Aragorn]

On Wednesday 20 February 2013 22:02, Aragorn conveyed the following to
alt.os.linux.debian...

> For starters, there's no need to do that because - as Richard
> Kettlewell said - the "\n" already covers the hostname.

^^^^
That was a typo, of course. It should read "\h". "\n" represents a
newline character.

[Bill McCormick]

On 2/20/2013 3:04 PM, Aragorn wrote:
> On Wednesday 20 February 2013 22:02, Aragorn conveyed the following to
> alt.os.linux.debian...
>
>> For starters, there's no need to do that because - as Richard
>> Kettlewell said - the "\n" already covers the hostname.
> ^^^^
> That was a typo, of course. It should read "\h". "\n" represents a
> newline character.
>

I want to make only a portion of the FQDN part of the prompt:

PS1='${debian_chroot:+($debian_chroot)}\u@$(hostname -f|sed
's/\.example\.domain\.name//'):\w\$ '

[Richard Kettlewell]

Bill McCormick <wpmcc...@gmail.com> writes:
> Aragorn wrote:

>> Aragorn wrote:

>>> For starters, there's no need to do that because - as Richard
>>> Kettlewell said - the "\n" already covers the hostname.
>> ^^^^
>> That was a typo, of course. It should read "\h". "\n" represents a
>> newline character.
>
> I want to make only a portion of the FQDN part of the prompt:
>
> PS1='${debian_chroot:+($debian_chroot)}\u@$(hostname -f|sed
> s/\.example\.domain\.name//'):\w\$ '

You’ve been told twice that \h is the answer to this part of the
question. Why are you even asking if you’re not going to pay attention
to the answer?

(If you only want “a portion” of the hostname then another answer is the
to use the string ".", which unless you own a TLD is going to a portion
of every hostname you have; just not a very useful one.)

--
http://www.greenend.org.uk/rjk/

[Chris F.A. Johnson]

In /etc/bashrc and /etc/profile:

readonly PS1

However, the user can always start a new shell which doesn't source
those files.

--
Chris F.A. Johnson, <http://cfajohnson.com>
Author:
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)