Bug 17175

On Sat, 04 Mar 2000 19:44:21 +1000, Phil Homewood wrote:

> 	Create lots of symlinks from /tmp/p$$ to something
> 	interesting. Run send-pr, or wait for your victim to do
> 	so. Observe target file now containing victim's name.

This only works when the user running send-pr has write permission on
the affected file, right?

While this should be fixed, it's certainly not a show-stopper if it's
just a user-to-user annoyance.  Nobody sensible runs send-pr as root.

So, assuming I'm right about the urgency involved,  have you
investigated the possibility of a patch from the vendor?  Although the
send-pr.sh file isn't on the vendor branch any more, it'd make sense to
try to use a vendor-supplied patch.

Ciao,
Sheldon.

OOPS. Previous patch is mildly bogus. This one works better.

--- src/gnu/usr.bin/send-pr/send-pr.sh.orig     Sat Sep  4 06:06:55 1999
+++ src/gnu/usr.bin/send-pr/send-pr.sh  Sat Mar  4 20:01:14 2000
@@ -75,9 +75,9 @@
 
 [ -z "$TMPDIR" ] && TMPDIR=/tmp
 
-TEMP=$TMPDIR/p$$
-BAD=$TMPDIR/pbad$$
-REF=$TMPDIR/pf$$
+TEMP=`mktemp -t send-pr.p` || exit 1
+BAD=`mktemp -t send-pr.pbad` || exit 1
+REF=`mktemp -t send-pr.pf` || exit 1
 
 if [ -z "$LOGNAME" -a -n "$USER" ]; then
   LOGNAME=$USER

-- 
Phil Homewood        dot@atat.dotat.org        phil@rivendell.apana.org.au
           Member, Australian Public Access Network Association

Sheldon Hearn wrote:
> This only works when the user running send-pr has write permission on
> the affected file, right?

Yes.

> While this should be fixed, it's certainly not a show-stopper if it's
> just a user-to-user annoyance.  Nobody sensible runs send-pr as root.

You're assuming sensible users. Bad move. :-)
I still think it's serious enough to warrant a fix.

> So, assuming I'm right about the urgency involved,  have you
> investigated the possibility of a patch from the vendor?  Although the
> send-pr.sh file isn't on the vendor branch any more, it'd make sense to
> try to use a vendor-supplied patch.

PR has been submitted to vendor as well. "gnats/52" is the Cygnus
tracking ID.

Note too my followup patch (initial one erroneously took out the
'[ -z "$TMPDIR" ] && TMPDIR=/tmp' line which is still needed.
Sorry 'bout that. :-)
-- 
Phil Homewood        dot@atat.dotat.org        phil@rivendell.apana.org.au
           Member, Australian Public Access Network Association

On Sat, 04 Mar 2000 20:12:12 +1000, Phil Homewood wrote:

> I still think it's serious enough to warrant a fix.

Oh absolutely!  I'm just saying that we can probably wait for the GNU
people to settle on an official patch before applying it.

How long do you think it'll take for them to close their PR?

Ciao,
Sheldon.

Sheldon Hearn wrote:
> Oh absolutely!  I'm just saying that we can probably wait for the GNU
> people to settle on an official patch before applying it.
> 
> How long do you think it'll take for them to close their PR?

No idea. First time I've ever logged a PR there, and I submitted
it around the same time I submitted this one. (Didn't supply a
patch to the GNATS people though, as we're not on vendor branch,
and mktemp(1) isn't exactly portable anyway.)
-- 
Phil Homewood        dot@atat.dotat.org        phil@rivendell.apana.org.au
           Member, Australian Public Access Network Association

On Sat, 04 Mar 2000 20:20:13 +1000, Phil Homewood wrote:

> No idea. First time I've ever logged a PR there, and I submitted
> it around the same time I submitted this one.

Any news from the GNATS people?

Ciao,
Sheldon.

Sheldon Hearn wrote:
> Any news from the GNATS people?

None. The PR is sitting "open", nobody has yet touched it.
-- 
Phil Homewood        dot@atat.dotat.org        phil@rivendell.apana.org.au
           Member, Australian Public Access Network Association

On Wed, 15 Mar 2000 22:08:13 +1000, Phil Homewood wrote:

> None. The PR is sitting "open", nobody has yet touched it.

Well, since the file is off the vendor branch, we may as well smack it
if the GNATS people aren't in hurry. :-)

Ciao,
Sheldon.

Comment 9 Sheldon Hearn 2000-03-15 12:21:27 UTC

State Changed
From-To: open->closed

Duplicate of PR 16942.  There's a forward reference on that PR to this 
one, so closing this one loses us nothing.