Re: How do we intercept file saving or output to stdout directly

From	Greg Wooledge <wooledg@eeg.ccf.org>
Newsgroups	gnu.bash.bug
Subject	Re: How do we intercept file saving or output to stdout directly
Date	2020-08-27 07:24 -0400
Message-ID	<mailman.1466.1598527478.2469.bug-bash@gnu.org> (permalink)
References	<20200826121352.GN931@eeg.ccf.org> <1598249852364-0.post@n7.nabble.com> <87a6yinjhl.fsf@hobgoblin.ariadne.com> <6237.1598480806@jinx.noi.kre.to> <20200827112434.GT931@eeg.ccf.org>

Show all headers | View raw

On Thu, Aug 27, 2020 at 05:26:46AM +0700, Robert Elz wrote:
>  28469  28469 xkbcomp  CALL  unlink(0x7f7fffffec7b)
>  28469  28469 xkbcomp  NAMI  "/dev/stdout"
>  28469  28469 xkbcomp  RET   unlink -1 errno 13 Permission denied
>  28469  28469 xkbcomp  CALL  open(0x7f7fffffec7b,0xa01,0x1b6)
>  28469  28469 xkbcomp  NAMI  "/dev/stdout"
>  28469  28469 xkbcomp  RET   open -1 errno 17 File exists

Ahh.  Then I revise my guess to "an attempt to prevent someone sneaking
in a symlink between the unlink and the open", i.e. classic race condition
security for publically writable directories like /tmp.

Back to gnu.bash.bug | Previous | Next | Find similar

Thread

Re: How do we intercept file saving or output to stdout directly Greg Wooledge <wooledg@eeg.ccf.org> - 2020-08-27 07:24 -0400

csiph-web