On 5/1/25 10:29, Chet Ramey wrote:
On 4/30/25 6:23 PM, Rob Landley wrote:
Somebody forwarded that to me from an exploit how-to site. It's
apparently a trick used to subvert scripts that call things via
absolute path to avoid malicious $PATH.
I suppose if you can get a script to source an arbitrary file, you can do
pretty much anything.
$ command /usr/bin/whoami
landley
$ command() { echo nope; }
$ command /usr/bin/whoami
nope
What was the _benefit_ of allowing / in command names?
$ x() { echo hello; }; D=x; $D
hello
OK? Commands are parsed, then executed.
To me, that seemed like analogous behavior working on the same line.
Mostly the use of alias I've encountered seems to be things like alias
ls='ls -l' allowing additional arguments, although ls() { ls -l "$@"; }
seems like it could do it too. The _unique_ feature is stuff like:
$ alias ls='ls >'
$ ls
bash: syntax error near unexpected token `newline'
Which I've never seen the utility of, other than people who do variants
of the old "define begin {" stuff pascal programmers used to do when
forced to use C...
Since alias expansion happens when the command is
read and tokenized,
Yeah, that was the weird part. My code breaks argv[] into separate
chunks but doesn't try to figure out what they _mean_ until it needs
to run them, because:
$ alias one='$X'
$ X='$A'; A=$X one
bash: $A: command not found
Is still figuring out that it has to move past the prefix assignment
to expand the alias, so you're saying your "tokenization" recognizes
prefix assignments...
Alias expansion happens on the first word of a simple command (for our
purposes here). The first word of a simple command that's going to be
eligible for alias expansion is a WORD, not an ASSIGNMENT_WORD.
The parser knows when it's going to read a command, so it knows when to
expect a simple command, and if it reads an assignment statement in that
position, it knows it's an ASSIGNMENT_WORD. Only WORDs in the right
position are eligible for alias expansion -- it's context-dependent.
It works for prefix assignments but not:
$ alias blah='echo hello'
$ >file blah
$ cat blah
cat: blah: No such file or directory
(Don't ask me why the error message went to stdout instead of stderr,
but the $ prompt goes to stderr. I think I need to walk away from the
keyboard for a bit...)
As POSIX puts it:
"Further distinction on TOKEN is context-dependent. It may be that the same
TOKEN yields WORD, a NAME, an ASSIGNMENT_WORD, or one of the reserved words
below, dependent upon the context."
the list will be parsed before any of the commands
are executed. This is how Bourne-style shells work.
The logic of what counts as a "line" in this context is unclear to me:
Oh, we had a rocking discussion about that topic, and the comments here
aren't half of it.
https://www.austingroupbugs.net/view.php?id=953
Oh joy.
$ bash -c $'echo $LINENO;alias a=b\necho $LINENO;a'
1
2
bash: line 2: a: command not found
Anywhere the shell executes a string (the command_string argument to
`sh -c', `eval', command substitution bodies), it parses the entire string
as a compound_list and then executes that list.
I just did fmemopen(buf, strlen(buf), "r") and fed it to the same line
reading loop as everything else. You're saying I should write extra code
to behave differently for the special case.
Wouldn't trigger (like it does for functions).
Then again busybox ash, mksh, zsh, and even dash are all doing this
too, so I guess "compatible" beats "sane". Maybe it's so you can do:
alias potato=fruitbat
source filename
unalias potato
See above about compound_list parsing.
Sigh.
And, of course:
$ alias one=two
$ on\e
bash: one: command not found
When that is tokenized, the backslash is still part of the word, so it
can't match an alias name.
Only because:
$ alias on\\e=two
bash: alias: `on\e': invalid alias name
Which function definition _doesn't_ do...
My first pass at implementing this just recycled the "is this a valid
variable name" logic:
$ abc/def=ghi
bash: abc/def=ghi: No such file or directory
But functions can have / in them for reasons.
Possibly I should just get this wrong and wait to see who complains...
Chet
Rob
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
