Date: Sat, 18 May 2024 23:00:41 +0000
From: Matheus Afonso Martins Moreira <math...@matheusmoreira.com>
Message-ID:
<dR9S605H035mFA4Mw-zMDA14EDUmIvWa1o1gFU_od76uOQJmf-y7ovpEAdpXWttQemhpexDfs3-1oL3PKJlRgT2MwLoTiMvIv4q_WfNUOPY=@matheusmoreira.com>
| If you resolve the path, you're just reinventing the source builtin.
Nonsense, the real work of the source ('.' really) utility is to
read the file, parse it, and execute it. None of the proposed
solutions here do that. What file names work for this purpose is
an irrelevant consideration.
| It also depends on source actually accepting the absolute path
| which renders it incompatible with restricted shells.
That's the only point here that has any merit. And a better solution
to that would be to remove that restriction, which has no purpose that
I can imagine. The commands run by the source builtin would be restricted,
and whatever they are, could simply be typed as input to the same effect,
so stopping a rbash user from accessing stuff in some common (full path
named) file seems pointless to me. Just remove that restriction and
this point goes away, and there's no reason left to modify bash in one
particular way (rather than some other way that someone else would prefer).
[Aside: the restriction on rbash using "exec" to replace the shell makes
no sense either - obviously whatever is exec'd would need to be a command
the user could run without exec, and assuming that condition is maintained,
then a user can just do "cmd" and stay in that until they're done, which
is effectively identical to "exec cmd" except the former keeps the rbash
process hanging around for no useful purpose.
I also find it hard to believe that anyone can usefully use any shell
which doesn't allow stdout to be redirected - what files can be used,
that can be restricted, but simply banning redirection? Weird.
Then again, my general opinion of restricted shells is that they were a
joke when first invented (long long ago when lots of users shared a
computer, which is a very rare setup these days) and while the joke has
become stale, that's still what they are.]
| I don't really understand why there seems to be so much
| opposition to this.
It is extra stuff that once added needs to be maintained forever.
Unless it proves useful, and unable to be done some other way,
adding it is typically the wrong thing to do.
| So why add the source builtin to begin with?
That one is simple ... when it ('.' in sh, "source" in csh) was added
there were no functions, while read & eval might have been enough for
simple one line scripts, they wouldn't work for more complex ones, to
invent your own '.' command that way you'd need to do it in a moderately
complex function, which didn't exist at the time. And like anything
else, once added, it is there forever.
| > if I needed something like that, I could write my own, similar ones.
| And you would run into the limitations described above.
I wouldn't, as I don't care about restricted shells (never have, not
even when I was running a system used by many hundreds of (*evil*)
students). And that's the only real restriction, which should be
removed anyway.
I agree that modifying PATH isn't a great solution - though for any
use I'd have of '.' that wouldn't bother me either (both because I've
never used a '.' command that actually searches PATH, and because I
don't put anything which would require a PATH search in files I use
via '.' - such scripts are simply run as scripts. '.' is used when
the current shell environment needs to be modified, so is useful for
defining functions, and assigning values to variables (and perhaps
the odd option setting) - almost never anything more than that (at
least for me - so I wouldn't run into the limitations described.)
kre
