[net.bugs.uucp] uupick on hp 550 running hp-ux

mark@cogent.UUCP (Mark Steven Jeghers) (10/16/86)

Can anyone help me with a frustrating uucp bug?  It involves uupick.
When uupick is invoked, it goes through it's usual routine of displaying
one received file at a time and asking what to do with it.  THe problem
is that whenever I tell it where to move the file to, I am told that that
directory cannot be accessed.  Thie happens regardless of the ownerships
and permissions of the directory.  Even in a directory of my own, in my
current group, with 777 permission, this error occurs.  The error goes
away, however, if I am super-user or root.

Obviously I cannot give root power to anyone who merely wants to use
public file transfers!  Please e-mail and I will post results and
credits afterwards.

I am running HP-UX on an HP 550.  I am not discounting the possibility
of bugs in HP's own implementation of UN*X and/or uucp (after all, nobody's
perfect).  Any ideas, HP people?

Thanx,

Mark Jeghers

{dual,ptsfa}|cogent!mark

stuart@BMS-AT.UUCP (Stuart D. Gathman) (10/18/86)

In article <17@cogent.UUCP>, mark@cogent.UUCP (Mark Steven Jeghers) writes:

> one received file at a time and asking what to do with it.  THe problem
> is that whenever I tell it where to move the file to, I am told that that
> directory cannot be accessed.

Our SCO Xenix system had the same bug.  The problem is that uupick was
written as a shell script and all the public directories were owned
by uucp with no write permission for 'other'.  I fixed the problem by
changing the permissions on all public directories to 777.  There is still
a problem when new public directories are created, but I can fix those
as they come along.  The real solution is to write a suid version of uupick
in 'C' or to fix whoever creates the default permissions and owners.
-- 
Stuart D. Gathman	<..!seismo!{vrdxhq|dgis}!BMS-AT!stuart>

levy@ttrdc.UUCP (Daniel R. Levy) (10/19/86)

Please forgive the followup, but I feel uncertain that I can find a good mail
path back to you (ihnp4 gets a bit moody these days) and I want to provide a
speedy reply.

In article <17@cogent.UUCP>, mark@cogent.UUCP (Mark Steven Jeghers) writes:
>Can anyone help me with a frustrating uucp bug?  It involves uupick.
>When uupick is invoked, it goes through it's usual routine of displaying
>one received file at a time and asking what to do with it.  THe problem
>is that whenever I tell it where to move the file to, I am told that that
>directory cannot be accessed.  Thie happens regardless of the ownerships
>and permissions of the directory.  Even in a directory of my own, in my
>current group, with 777 permission, this error occurs.  The error goes
>away, however, if I am super-user or root.
>Obviously I cannot give root power to anyone who merely wants to use
>public file transfers!  Please e-mail and I will post results and
>credits afterwards.
>I am running HP-UX on an HP 550.  I am not discounting the possibility
>of bugs in HP's own implementation of UN*X and/or uucp (after all, nobody's
>perfect).  Any ideas, HP people?
>Thanx,
>Mark Jeghers
>{dual,ptsfa}|cogent!mark

uupick is a shell script on SysV (dunno about HP-UX).  If it IS a shell script
on HP-UX (use the "file" command, don't just cat it out cold if it happens to
be a binary there) then just do

sh -xv /usr/bin/uupick		# or wherever your uupick resides

It copies files out of /usr/spool/uucppublic/receive/USERNAME/SYSTEMNAME/
where USERNAME is your user name and SYSTEMNAME is your system name.
Invoke uupick with shell debug on and you will easily be able to see what
it is trying to do.  Then you can follow up appropriately.
--
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
	   go for it!  			allegra,ulysses,vax135}!ttrdc!levy
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
	   go for it!  			allegra,ulysses,vax135}!ttrdc!levy