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
ch...@cfajohnson.com 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 yes in yes) echo yes
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; ;;
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 tomorrow
which I presume relies on acceptance of /tmp/exploit=me as a possible
command. I'm not sure it does since the current
| 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 jon.seym...@gmail.com wrote:
To clarify, I am not sure that the presence of a variable called
/tmp/exploit=me represents a huge vuilnerability for at(1
On Tue, May 29, 2012 at 1:08 AM, Eric Blake ebl...@redhat.com 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 of promoting interoperable
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
On 27/05/2012, at 17:39, Geir Hauge geir.ha...@gmail.com wrote:
2012/5/27 Jon Seymour jon.seym...@gmail.com:
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
On Sun, May 27, 2012 at 9:24 PM, Dan Douglas orm...@gmail.com wrote:
On Sunday, May 27, 2012 08:45:46 PM Jon Seymour wrote:
On 27/05/2012, at 17:39, Geir Hauge geir.ha...@gmail.com wrote:
I guess the question is better phrased thus: what use case is usefully
served by having bash's POSIX mode
On Sun, May 27, 2012 at 9:31 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Jon Seymour jon.seym...@gmail.com 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 running in POSIX
On Sun, May 27, 2012 at 11:09 PM, Jon Seymour jon.seym...@gmail.com wrote:
On Sun, May 27, 2012 at 9:31 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Jon Seymour jon.seymour@gm
** I guess I can except that current bash behaviour is, on balance,
except - accept
On Mon, May 28, 2012 at 2:08 AM, Dan Douglas orm...@gmail.com 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
On Mon, Aug 8, 2011 at 8:42 AM, Bob Proulx b...@proulx.com 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 mono...@sudrala.de 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://sudrala.de/en_d/shell-getlink.html
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 Tue, Aug 9, 2011 at 12:49 PM, Bob Proulx b...@proulx.com 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 available).
Try this:
ls -l /path
On Tue, Aug 9, 2011 at 1:36 PM, Bob Proulx b...@proulx.com 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 solution
anyway
On Tue, Aug 9, 2011 at 2:14 PM, Bob Proulx b...@proulx.com 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't quite enough -
particularly if the target of the link itself contains
On Tue, Aug 9, 2011 at 2:36 PM, Jon Seymour jon.seym...@gmail.com wrote:
On Tue, Aug 9, 2011 at 2:14 PM, Bob Proulx b...@proulx.com 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't
On Tue, Aug 9, 2011 at 2:51 PM, Bob Proulx b...@proulx.com wrote:
Jon Seymour wrote:
readlink_f()
{
local path=$1
test -z $path echo usage: readlink_f path 12 exit 1;
An extra ';' there that doesn't hurt but isn't needed.
local dir
if test -L $path
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
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 jon.seym...@gmail.com
Date: Sat, Feb 12, 2011 at 2:18 PM
Subject: Can someone explain
...@gmail.com wrote:
On Fri, Feb 11, 2011 at 9:21 PM, Jon Seymour jon.seym...@gmail.com wrote:
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
On Sat, Feb 12, 2011 at 4:54 PM, Bob Proulx b...@proulx.com 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
, Feb 6, 2011 at 11:51 AM, Jon Seymour jon.seym...@gmail.com 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 not used
On Sun, Feb 6, 2011 at 1:07 PM, Michael Witten mfwit...@gmail.com wrote:
On Sat, Feb 5, 2011 at 20:02, Michael Witten mfwit...@gmail.com 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
, 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 need to encode a list of filenames in a variable
POSIX shells won't have arrays (they're allowed
On Mon, Aug 30, 2010 at 11:33 PM, Greg Wooledge wool...@eeg.ccf.org 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. Most
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
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
Oh, cool. Thanks for correcting me!
jon.
On Sat, Dec 5, 2009 at 11:54 AM, Eric Blake e...@byu.net 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
with named pipes
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 wool...@eeg.ccf.org wrote:
On Mon, May 11, 2009 at 10:35:18AM +1000, Jon Seymour wrote:
I am trying
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:
echo
On Mon, Feb 23, 2009 at 4:03 PM, Mike Frysinger vap...@gentoo.org 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:
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 fn42...@fmi.uni-sofia.bg wrote:
Chet Ramey wrote:
Angel Tsankov wrote:
Hi,
Using bash 3.2.48(1)-release, echo ~root prints
On Mon, Feb 16, 2009 at 10:22 AM, Paul Jarc p...@po.cwru.edu wrote:
Jon Seymour jon.seym...@gmail.com 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
On Mon, Feb 16, 2009 at 12:11 PM, Paul Jarc p...@po.cwru.edu wrote:
Jon Seymour jon.seym...@gmail.com 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
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,
On Thu, Feb 12, 2009 at 8:02 AM, Paul Jarc p...@po.cwru.edu wrote:
Jon Seymour jon.seym...@gmail.com 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
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
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 PROTECTED
~/.bashrc?
jon seymour.
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.
-inventing the
wheel, I'd be interested in learning of other efforts in this area.
jon seymour.
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'
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.
46 matches
Mail list logo
