You do realise that if you allow an untrusted script to run at root, having
it modify itself is the least of your concerns. There are *so* many ways an
untrusted script can cause a problem that do not require your
self-modifying script and for which your proposed mitigation will do
nothing. What's
Thanks for reply and the workaround.
jon.
On Sun, Mar 22, 2015 at 4:49 PM, Chris F.A. Johnson
wrote:
> On Sun, 22 Mar 2015, Jon Seymour wrote:
>
>> I was surprised that this didn't work with the OSX version of bash 3.2:
>>
>> /bin/bash -c 'echo $(case &quo
I was surprised that this didn't work with the OSX version of bash 3.2:
/bin/bash -c 'echo $(case "yes" in yes) echo yes; ;; no) echo no; ;; esac)'
/bin/bash: -c: line 0: syntax error near unexpected token `;;'
/bin/bash: -c: line 0: `echo $(case "yes" in yes) echo yes; ;; no)
echo no; ;; es
| correction: variable called "/tmp/exploit=me" => a variable called
"/tmp/exploit" with a value "me"
On Mon, Sep 29, 2014 at 2:26 AM, Jon Seymour wrote:
> To clarify, I am not sure that the presence of a variable called
> "/tmp/exploit=me"
at sh can parse and allows exported functions to
>> be used in the environment that calls at.
>>
> ...
>
> Jon Seymour asked me if my at patch would fix the following vulnerablity
> (presumably in at(1))
>
> echo pwd | env "/tmp/exploit=me" at tomorr
On Tue, May 29, 2012 at 1:08 AM, Eric Blake wrote:
> On 05/27/2012 07:09 AM, Jon Seymour wrote:
>
>> I understand that the behaviour is unspecitied by POSIX - I didn't
>> know that before, but I know that now - thanks.
>>
>> That said, from the point of view
On Mon, May 28, 2012 at 2:08 AM, Dan Douglas wrote:
> ... Bash
> just modifies conflicting features to the minimal extent necessary to bring it
> into compliance, which seems to be the path of least resistance.
>
Sure. I understand that this is a reasonable philosophy given that
aiming for comple
On Sun, May 27, 2012 at 11:09 PM, Jon Seymour wrote:
> On Sun, May 27, 2012 at 9:31 PM, Andreas Schwab wrote:
>> Jon Seymour
> ** I guess I can except that current bash behaviour is, on balance,
except -> accept
On Sun, May 27, 2012 at 9:31 PM, Andreas Schwab wrote:
> Jon Seymour writes:
>
>> As it stands, I can't use bash's POSIX mode to verify the validity or
>> otherwise of a POSIX script because bash won't report these kinds of
>> errors - even when runni
On Sun, May 27, 2012 at 9:24 PM, Dan Douglas wrote:
> On Sunday, May 27, 2012 08:45:46 PM Jon Seymour wrote:
>> On 27/05/2012, at 17:39, Geir Hauge wrote:
>>
>> I guess the question is better phrased thus: what use case is usefully
> served by having bash's POSIX mo
On 27/05/2012, at 17:39, Geir Hauge wrote:
> 2012/5/27 Jon Seymour :
>> Is there a reason why bash doesn't treat == as an illegal test
>> operator when running in POSIX mode?
>
> POSIX does not say == is not allowed.
>
> POSIX tells you what the shell should
Is there a reason why bash doesn't treat == as an illegal test
operator when running in POSIX mode?
This is problematic because use of test == in scripts that should be
POSIX isn't getting caught when I run them under bash's POSIX mode.
The scripts then fail when run under dash which seems to be s
On Mon, Aug 8, 2011 at 8:42 AM, Bob Proulx wrote:
>
> People sometimes read the POSIX standard today and think it is a
> design document. Let me correct that misunderstanding. It is not.
> POSIX is an operating system non-proliferation treaty.
Love it!
jon.
On Tue, Aug 9, 2011 at 7:29 PM, Bernd Eggink wrote:
> On 09.08.2011 03:44, Jon Seymour wrote:
>>
>> Has anyone ever come across an equivalent to Linux's readlink -f that
>> is implemented purely in bash?
>
> You can find my version here:
>
> http://sud
On Tue, Aug 9, 2011 at 2:51 PM, Bob Proulx wrote:
> Jon Seymour wrote:
>> readlink_f()
>> {
>> local path="$1"
>> test -z "$path" && echo "usage: readlink_f path" 1>&2 && exit 1;
>
> An extra
On Tue, Aug 9, 2011 at 2:36 PM, Jon Seymour wrote:
> On Tue, Aug 9, 2011 at 2:14 PM, Bob Proulx wrote:
>> Jon Seymour wrote:
>>> I always use sed for this purpose, so:
>>>
>>> $(cd "$dir"; ls -l "$base" | sed "s/.*->//"
On Tue, Aug 9, 2011 at 2:14 PM, Bob Proulx wrote:
> Jon Seymour wrote:
>> I always use sed for this purpose, so:
>>
>> $(cd "$dir"; ls -l "$base" | sed "s/.*->//")
>>
>> But, with pathological linking structures, this isn
On Tue, Aug 9, 2011 at 1:36 PM, Bob Proulx wrote:
> Jon Seymour wrote:
>> readlink -f will fully resolve links in the path itself (rather than
>> link at the end of the path), which was the behaviour I needed.
>
> Ah, yes, well, as you could tell that was just a partial solut
On Tue, Aug 9, 2011 at 12:49 PM, Bob Proulx wrote:
> Jon Seymour wrote:
>> Has anyone ever come across an equivalent to Linux's readlink -f that
>> is implemented purely in bash?
>>
>> (I need readlink's function on AIX where it doesn't seem to be ava
Has anyone ever come across an equivalent to Linux's readlink -f that
is implemented purely in bash?
(I need readlink's function on AIX where it doesn't seem to be available).
jon.
On Sat, Feb 12, 2011 at 4:54 PM, Bob Proulx wrote:
> I am a big fan of piping the script to the remote shell.
>
> $ echo "cd /tmp && pwd" | ssh example.com bash
> /tmp
>
> This has two advantages. One is that you can pick your shell on the
> remote host. Otherwise it runs as whatever is config
o $$ runs in the parent shell
jon.
On Sat, Feb 12, 2011 at 2:44 PM, Dennis Williamson
wrote:
> On Fri, Feb 11, 2011 at 9:21 PM, Jon Seymour wrote:
>> Correction - a _leading_ cd command and only a leading cd command,
>> seems to be completely ignored in the case I described.
>
Correction - a _leading_ cd command and only a leading cd command,
seems to be completely ignored in the case I described.
Why is this?
jon.
-- Forwarded message --
From: Jon Seymour
Date: Sat, Feb 12, 2011 at 2:18 PM
Subject: Can someone explain this?
To: bug-bash@gnu.org
Can someone explain why this is happening?
#expected
$ bash -c 'cd /tmp; pwd'
/tmp
#expected
$ bash -c 'pwd; cd /tmp; pwd'
/home/jseymour
/tmp
#expected
$ ssh localhost bash -c 'pwd; cd /tmp; pwd'
/home/jseymour
/tmp
#unexpected
$ ssh localhost bash -c 'cd /tmp; pwd'
/home/jseymour
My expectat
Good catch - how long did that take to find?
jon.
On Thu, Feb 10, 2011 at 6:06 AM, Eric Blake wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> -DCONF_O
On Sun, Feb 6, 2011 at 1:07 PM, Michael Witten wrote:
> On Sat, Feb 5, 2011 at 20:02, Michael Witten wrote:
>> So, if you run `history', you'll not only get the commands in the
>> history list, but you'll also get the time at which the commands
>> were last run (formatted according to "$HISTTIMEF
On Sun, Feb 6, 2011 at 1:02 PM, Michael Witten wrote:
> On Sat, Feb 5, 2011 at 19:15, Jon Seymour wrote:
>
> So, if you run `history', you'll not only get the commands in the
> history list, but you'll also get the time at which the commands
> were la
jon.
On Sun, Feb 6, 2011 at 11:51 AM, Jon Seymour wrote:
> In the version I was using a line that began with # and perhaps a timestamp
> separated each entry of the history in a way that in principle preserved
> information about the entry boundary even though this information is no
, Michael Witten wrote:
> On Sat, Feb 5, 2011 at 18:02, Jon Seymour wrote:
>> The version I tried on Linux 3.2.25 does have a .bash_history
>> format that could support it, but it still behaved the same way.
>
> How do you mean?
>
> I'm running bash version "4.
On Sun, Feb 6, 2011 at 10:51 AM, Bob Proulx wrote:
> Slevin McGuigan wrote:
>> I am unsure whether or not this a bug. Anyhow, it is pretty annoying...
>>
>> I use simple multi-line scripts very often in bash and use vi mode
>> to edit them. By using
>> # shopt -s cmdhist
>> # shopt -s lithist
>> I
On Mon, Aug 30, 2010 at 11:33 PM, Greg Wooledge wrote:
> On Mon, Aug 30, 2010 at 11:25:00PM +1000, Jon Seymour wrote:
>> I am working on an extension to git, and need to store a list of shell
>> files that can be used to extend the capabilities of the command I am
>> writing
g Wooledge wrote:
> On Sun, Aug 29, 2010 at 04:07:23AM -0400, Chris F.A. Johnson wrote:
>> On Sun, 29 Aug 2010, Jon Seymour wrote:
>>
>> >This isn't strictly a bash question, and I'd prefer a POSIX-only
>> >solution if possible
>
>> >Suppose I nee
| question -> _forum_
On 8/29/10, Jon Seymour wrote:
> This isn't strictly a bash question, and I'd prefer a POSIX-only
> solution if possible [ suggestions as to a good _forum_ to ask
> POSIX-only questions would be appreciated ].
>
> Suppose I need to encode a lis
This isn't strictly a bash question, and I'd prefer a POSIX-only
solution if possible [ suggestions as to a good question to ask
POSIX-only questions would be appreciated ].
Suppose I need to encode a list of filenames in a variable and each
filename may contain spaces, what is good way to encode
I too was unaware of the HISTCONTROL option, but now that I know what
it does, I am intrigued by the rationale for HISTCONTROL=ignorespace?
In other words, what motivated the inclusion of handling for this
option specifically?
Is it to allow users who may have reason to type sensitive commands a
t
If you can, it is better to restructure what you want to do by passing the
arguments to the target command on stdin, rather than on the command line. I
realise that this may not be possible in all cases, but it is generally the
preferred approach if you can achieve it.
The advantage is that your r
Oh, cool. Thanks for correcting me!
jon.
On Sat, Dec 5, 2009 at 11:54 AM, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to Jon Seymour on 12/4/2009 4:00 PM:
>> On Linux or any reasonable OS, I could do this remote dispatch easily
>&g
I'd like to dispatch commands from one light-weight bash process to a
longer running bash process which takes longer to initialize [ I have
a _big_ library of bash functions ].
On Linux or any reasonable OS, I could do this remote dispatch easily
with named pipes, but these don't exist on cygwin.
There are at least 3 things wrong with your snippet.
Try:
IPS=(( 89.17.206.180 89.17.206.185 89.17.206.186 89.17.206.187 ))
for k in ${i...@]}
do
nmap -p 22 $k
done
jon.
On 07/07/2009, at 4:55 AM, tirengarfio wrote:
IPS={89.17.206.180,89.17.206.185,89.17.206.186,89.17.206.187}
Yes, I realised that I should have at least used // after I posted,
not that that would have been sufficient. Thanks for the solution.
jon.
On Mon, May 11, 2009 at 10:20 PM, Greg Wooledge wrote:
> On Mon, May 11, 2009 at 10:35:18AM +1000, Jon Seymour wrote:
>> I am trying to parse
I am trying to parse untrusted strings and represent in a form that
would be safe to execute.
So assuming as-echo.sh defined as below for example:
cmd="echo"
for a in "$@"
do
cmd="$cmd '${a/\'/''}'"
done
echo "$cmd"
eval "$cmd"
Then:
as-echo.sh 'a' '$(foobar)' 'c'
would produce:
On Mon, Feb 23, 2009 at 4:03 PM, Mike Frysinger wrote:
> previous versions of bash would happily accept negative values ( treated as a
> signed integer and masked with like 0xff), but it seems some changes related
> to option parsing has broken that
>
> $ f(){ return -1; }; f
> -bash: return: -1:
On Mon, Feb 16, 2009 at 12:11 PM, Paul Jarc wrote:
> Jon Seymour wrote:
>> The manual specifies a rule for ${parameter:+word}, but not
>> ${parameter+word}.
>
> It's there, but easy to miss:
> In each of the cases below, word is subject to tilde expansion, p
d too.
$@ wouldn't work if the positional parameters in the current context
happened to be empty as is easily demonstrated.
echo $...@+~jon} -> empty
echo ${?+~jon} -> /home/jon
echo ${#+~jon} -> /home/jon
jon.
On Mon, Feb 16, 2009 at 11:49 AM, Angel Tsankov
wrote:
> Paul Jarc wrote:
On Mon, Feb 16, 2009 at 11:44 AM, Paul Jarc wrote:
> Jon Seymour wrote:
>> On Mon, Feb 16, 2009 at 10:22 AM, Paul Jarc wrote:
>>> CPATH=${CPATH:+$CPATH:}${#+~usr1/blah/blah}
>>
>> Out of interest, how does one derive that outcome from the documented
>&g
On Mon, Feb 16, 2009 at 10:22 AM, Paul Jarc wrote:
> Jon Seymour wrote:
>> If the builtin echo fails it will be because the bash interpreter has
>> suffered a catastrophic failure of some kind [ e.g. run out of memory
>> ]. Once that has happened, all bets are off anyway.
&
reconsider, since command substitution is one of
bash's most powerful features.
[ Of course, others more experienced with bash idioms may object to
$(echo ~usr1/blah/blah) on aesthetic grounds too - I welcome any
suggested improvement!. ]
jon.
On Mon, Feb 16, 2009 at 9:54 AM, Angel Tsankov wrote:
On Mon, Feb 16, 2009 at 9:26 AM, Angel Tsankov wrote:
> Jon Seymour wrote:
>> There may be other ways to do this, but:
>>
>> CPATH="${CPATH}${CPATH:+:}$(echo ~usr1/blah/blah)"
>>
>> should work.
>
> Well, I'd like to avoid the use of
There may be other ways to do this, but:
CPATH="${CPATH}${CPATH:+:}$(echo ~usr1/blah/blah)"
should work.
jon.
On Mon, Feb 16, 2009 at 9:02 AM, Angel Tsankov wrote:
> Chet Ramey wrote:
>> Angel Tsankov wrote:
>>> Hi,
>>>
>>> Using bash 3.2.48(1)-release, echo ""~root prints ~root instead
On Thu, Feb 12, 2009 at 8:02 AM, Paul Jarc wrote:
> Jon Seymour wrote:
>> Not sure this is correct. The ] is parsed by the shell
>
> It's parsed by the [ command. That happens to be a builtin command,
> so yes, it is done by the shell, but it is not part of the grammar
Not sure this is correct. The ] is parsed by the shell but only if it
surrounded by whitespace. This is why the -n option reports an error,
since -n suppresses command execution.
I suspect the behaviour is required by posix or at least historical
precedent.
jon.
On 12/02/2009, at 7:04, p
G'day,
This working as documented.
The relevant part of the manual is, I think:
"Bash always reads at least one complete line of input before
executing any of the commands on that line. Aliases are
expanded when a command is read, not when it is executed."
If aaa is not already
If you can, make the target of your ssh invocation a wrapper script
that sources .bashrc and then executes the remaining arguments.
Something like (in /usr/bin/local/ssh-target.sh):
#!/usr/bin/env bash
.[ -f ~/.bashrc ] && . ~/.bashrc
"$@"
ssh [EMAIL PROTECTED] /usr/local/bin/ssh-target.sh cmd
Chet,
Thanks for that info.
Due to the circumstances, recompiling bash isn't really an option for me, so
I decided to deal with it by having ssh invoke a script that could guarantee
~/.bashrc was sourced.
Regards,
jon seymour.
On Wed, Oct 15, 2008 at 1:24 PM, Chet Ramey <[EMAIL P
re any way I can have an ssh pseudo-tty and get bash to execute
~/.bashrc?
jon seymour.
hen guard the call to the those
functions with enclosing subshells as required - that's a choice you make in
bool_foo.
I agree a formal exception mechanism would be nice, but I have found that
use of exit and the subshell feature does allow most exception handling
patterns to be emulated reasonably well.
jon seymour.
effort re-inventing the
wheel, I'd be interested in learning of other efforts in this area.
jon seymour.
Apologies, I see that is true.
jon.
On Fri, Aug 15, 2008 at 3:36 PM, Pierre Gaston <[EMAIL PROTECTED]> wrote:
> It's listed in the BUGS section of my man page (last line of the page):
> "Array variables may not (yet) be exported."
>
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: cygwin
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='cygwin' -DCONF_MACHTYPE='i686-pc-cygwin'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKA\
GE='bash' -
59 matches
Mail list logo
