Unix Shell - Possible to export a readonly variable as readonly in bash?

Author

Possible to export a readonly variable as readonly in bash?

krsyoung

2006-01-20, 6:03 pm

Hello all,

I am just curious if anyone is familiar with a way (direct or
indirectly) to export a variable as readonly. I know if I do a declare
-rx VAR=foo then when I run a sub shell I can unset VAR with no
problem. I'm trying to set a value that lasts the entire duration of a
user's session.

(same problem with readonly VAR=foo)

Any help or suggestions would be much appreciated.

Thanks!
Chris

Bruce Barnett

2006-01-21, 7:49 am

"krsyoung" <krsyoung@gmail.com> writes:

> Hello all,
>
> I am just curious if anyone is familiar with a way (direct or
> indirectly) to export a variable as readonly. I know if I do a declare
> -rx VAR=foo then when I run a sub shell I can unset VAR with no
> problem. I'm trying to set a value that lasts the entire duration of a
> user's session.

Any shell can change any variable. The value at the parent shell will
not change.

If you are trying to provide some sort of security, it's the wrong way
to do it. Let the users do whatever they want. If they screw up, it
should affect their environment, and not affect the other
users. That's what the OS is suppose to do.

--
Sending unsolicited commercial e-mail to this account incurs a fee of
$500 per message, and acknowledges the legality of this contract.

Dan Mercer

2006-01-22, 6:10 pm

"krsyoung" <krsyoung@gmail.com> wrote in message news:1137779698.041254.205660@g47g2000cwa.googlegroups.com...
: Hello all,
:
: I am just curious if anyone is familiar with a way (direct or
: indirectly) to export a variable as readonly. I know if I do a declare
: -rx VAR=foo then when I run a sub shell I can unset VAR with no
: problem. I'm trying to set a value that lasts the entire duration of a
: user's session.
:
: (same problem with readonly VAR=foo)
:
: Any help or suggestions would be much appreciated.
:
: Thanks!
: Chris

You can do it in (real) ksh:

typeset -xr vname=value

Dan Mercer

:

krsyoung

2006-01-22, 6:10 pm

Ok, it must be bash that implements it a different way. It seems that
the readonly setting is only effective in the shell where the readonly
call was made. typeset is just an alias to declare, and the declare -xr
didn't quite pull it off.

As for Bruce's comment, I agree. This is not for security but auditing
purposes. It would be ideal for me to track a user logging out of a
shell, but it requires me to have access to a variable that is defined
at login time (major simplification).

What confuses me, if I login, then spawn a new shell and logout. Which
shell is running the .bash_logout script?

Thanks Bruce and Dan for the comments.

Bill Marcum

2006-01-22, 6:10 pm

On 21 Jan 2006 16:26:51 -0800, krsyoung
<krsyoung@gmail.com> wrote:
>
> What confuses me, if I login, then spawn a new shell and logout. Which
> shell is running the .bash_logout script?
>
Unless you exec a new shell, the original shell is still there, waiting
for the new shell to terminate. If you exec a shell other than bash,
the .bash_logout script will not be executed.

--
"I keep seeing spots in front of my eyes."
"Did you ever see a doctor?"
"No, just spots."

Chris F.A. Johnson

2006-01-22, 6:11 pm

On 2006-01-22, krsyoung wrote:
[snip]
>
> What confuses me, if I login, then spawn a new shell and logout. Which
> shell is running the .bash_logout script?

man bash:

When a login shell exits, bash reads and executes commands from
the file ~/.bash_logout, if it exists.

--
Chris F.A. Johnson, author | <http://cfaj.freeshell.org>
Shell Scripting Recipes: | My code in this post, if any,
A Problem-Solution Approach | is released under the
2005, Apress | GNU General Public Licence

krsyoung

2006-01-23, 2:55 am

Basically this is a shoddy solution and probably isn't worth pursuing
:-) But for history's sake.

Chris, as for the .bash_logout script, I'll clarify it a bit

1. I login (while the shell is being setup the following is executed
declare -xr FOO=bar)
2. unset FOO fails, it is readonly
3. bash, spawn a new shell process
4. unset FOO, no problemo, it is not readonly in this shell
5. logout (.bash_logout is executed in the current bash subshell, so
the script referencing FOO results in a null value)

I think this makes the scenario a little more clear. I think Bill
was working his way to getting at this. New shell = new rules. Even
if I have the variable readonly in the initial login shell, it is
whatever shell I am currently executing that runs the .bash_logout (and
its associated environment variables). A bit of a bummer. I'll have
to play around with it some more to triple check this theory.

Thanks again for the suggestions everyone.
Chris

Chris F.A. Johnson

2006-01-23, 2:55 am

On 2006-01-23, krsyoung wrote:
> Basically this is a shoddy solution and probably isn't worth pursuing
>:-) But for history's sake.

For clarity's sake please quote what you are referring to.

You will notice that I quoted the question I was answering.

> Chris, as for the .bash_logout script, I'll clarify it a bit
>
> 1. I login (while the shell is being setup the following is executed
> declare -xr FOO=bar)
> 2. unset FOO fails, it is readonly
> 3. bash, spawn a new shell process
> 4. unset FOO, no problemo, it is not readonly in this shell
> 5. logout (.bash_logout is executed in the current bash subshell, so
> the script referencing FOO results in a null value)

[Re]read what the man page says:

When a login shell exits, bash reads and executes commands from
the file ~/.bash_logout, if it exists.

IOW, if you spawn a new shell, it is not a login shell (unless you
expressly invoke it as such), and therefore will not run
.bash_logout on exit.

> I think this makes the scenario a little more clear. I think Bill
> was working his way to getting at this. New shell = new rules. Even
> if I have the variable readonly in the initial login shell, it is
> whatever shell I am currently executing that runs the .bash_logout (and
> its associated environment variables). A bit of a bummer. I'll have
> to play around with it some more to triple check this theory.
>
> Thanks again for the suggestions everyone.
> Chris
>

--
Chris F.A. Johnson, author | <http://cfaj.freeshell.org>
Shell Scripting Recipes: | My code in this post, if any,
A Problem-Solution Approach | is released under the
2005, Apress | GNU General Public Licence

krsyoung

2006-01-23, 8:49 pm

> For clarity's sake please quote what you are referring to.

Thanks for the tip

> [Re]read what the man page says:

> When a login shell exits, bash reads and executes commands from
> the file ~/.bash_logout, if it exists.

> IOW, if you spawn a new shell, it is not a login shell (unless you
> expressly invoke it as such), and therefore will not run .bash_logout on exit.

Ok, I understand this. To avoid these specifics basically it is not
possible to have a variable persist readonly throughout subshells.
That was my real question.

Chris, the .bash_logout comment you made causes challenges in the
process, if a user runs "bash -l", then "exit" it logs out of their
spawned shell(and does the administrative work that I only want to
happen when they logout completely). The other problem is if a ssh
connection is simply closed, then the .bash_logout script isn't
executed. However if a user spawns a new non-login shell, logs out,
and then logs out of the login shell the process does work correctly.

Thanks for the help
Chris