🚀 go-pugleaf

/ wdl1:comp.bugs.sys5 / monte@oblio.UUCP (Monte Pickard) / 10:32 pm  Jan 11, 1987 /
Seems to me that allowing /etc/mvdir to move /etc is a bug. 
The script requires that /etc exists to complete successfully.
(This is true in SVR2 and SVR3)
Does anyone agree?
----------

In my humble opinion, the very *existence* of mvdir as separate
from the normal mv command is a bug.

There is nothing in the filesystem that prevents a C program
from moving a directory from point A to point B in one filesystem.
But the System V mv command only moves directories laterally
(i.e., will only rename them within the same parent directory).

And I can see no reason that Joe User should have to come begging
to the superuser everytime he wants to make a trivial change
in his directory structure. If Joe User can rm his directories with
rmdir, why can't he move them? (on SV and SVR2, mvdir is rwxr--r--,
so only the superuser can move directories).

Seventh Edition UNIX had this facility (i.e., a mv command that
worked); in fact if you are source licensed for various UNIX source
versions you can run the V7 mv on system V and use it instead of mvdir.
I tried it once (when I worked at UofT and had source access) and it
worked; this is not a warranty that it will work on all versions of
System V for all time.

Seventh Edition UNIX came out in 1979 - hey, that's eight 
years ago. Too bad System V hasn't caught up technically.

As an exercise for the reader: write a C program that does
what mvdir does. You have to be root to run it, of course.

In article <1987Jan14.123035.20364@sq.uucp> ian@sq.UUCP (Ian F. Darwin) writes:
>
>In my humble opinion, the very *existence* of mvdir as separate
>from the normal mv command is a bug.

I agree completely.  This, and the implementation of ulimit(2), lead
me to wonder what AT&T were thinking of when they created S5.  I've
been trying for three months to convert from V7 to S5;  so far the only
advantages I can see in S5 are:

    1)	Greatly improved print spool mechanism (this is indeed a big win)
    2)	It's a "standard"

Against this must be balanced:

    1)	Above-mentioned bug (yes, bug) in mv
    2)	ulimit (ok, the idea isn't so bad, but the implementation is wrong)
    3)	adb is missing
    4)	dbm is missing
    5)	It's bigger and slower
    6)	The uucp node name is COMPILED into the kernel!

If it weren't for the impending arrival (S5R3) of streams and RFS,
I'd be tempted to give up, buy a source license, and back-port the print
spool stuff to V7.

Although I suspect the reasons are political and not technical, I wonder
if anyone at AT&T (or anyone else who thinks they know the real story)
could comment on why so much in S5 is missing and/or wrong.
-- 
Larry Campbell                                The Boston Software Works, Inc.
Internet: campbell@maynard.uucp             120 Fulton Street, Boston MA 02109
uucp: {alliant,wjh12}!maynard!campbell              +1 617 367 6846
ARPA: campbell%maynard.uucp@harvisr.harvard.edu      MCI: LCAMPBELL

In article <807@maynard.BSW.COM> campbell@maynard.UUCP (Larry Campbell) writes:
>In article <1987Jan14.123035.20364@sq.uucp> ian@sq.UUCP (Ian F. Darwin) writes:
>>In my humble opinion, the very *existence* of mvdir as separate
>>from the normal mv command is a bug.
>
>I agree completely.  [...]
>Against this [System V] must be balanced:
>    1)	Above-mentioned bug (yes, bug) in mv
>
>Although I suspect the reasons are political and not technical, I wonder
>if anyone at AT&T (or anyone else who thinks they know the real story)
>could comment on why so much in S5 is missing and/or wrong.

Gee, I though every one knew why they FIXED mv in System V.
It is a security loophole, isn't it obvious?  (:-)) That is why
they ONLY allow root to run it in SVR2.

Ok, now to get to the meat of the matter:
given directories d[0-1]*, where d0 is the base, and
files f[0-1]*, (e.g. d0/d1/f1*, d0/f0*),
d0 is drwxrwx--- user1 grp1, d1 is drwxr-x--- user2 grp1,
f1* is -rw-r----- user2 grp1,
in System V R2, I (being user3 grp1) I canNOT get `rid' of f1*
because I don't have write in d1,

but, if there existed mvdir in mv, or mvdir in general, then

I can mkdir d1new, selectively `cp d0/d1/* d0/d1new', and
now for the tricky part, `mvdir d0/d1 /tmp/kill_it_for_me',
and `mv d0/d1new d0/d1', put the files I WANT into d1,
after all I am now owner of it, I did the `mkdir', and then
restore all the modification and access times in d1, and
to cap it all off, `chown original_owner d0/d1/*', and
`chown original_owner d0/d1'.  All nice and tidy like.

And nobody would be the wiser.  If I could not `mvdir', the
original directory d0/d1 would have to be left in d0/.d1 or
something forever, and eventually somebody would spot it, and
say: `Gee, what is this?'  Oh, one thing, I am not sure if the
cron job (or whatever) runs in `root' but I would hope it
would, and thus, it, of course could kill the mvdir'ed
directory and recursively all the files in it for me.

Gee, some people actually don't know that Unix is not very
secure.  I know, don't flame me, I am not overly naive, it
is the problem with the person that set up the group write
priv on d0 that screwed it all up, but this is only due to
the fact that (properly) managing a Secure Unix is overly
complex.  I agree completely (I hope) that Unix (when
managed properly) is very secure.

I know this one little article is going to cause an avalanche
of of articles, but I feel I can say nothing to stop them...
-- 
Mike Stump, Cal State Univ, Northridge Comp Sci Department
uucp: {sdcrdcf, ihnp4, hplabs, ttidca, psivax, csustan}!csun!aeusemrs

In article <807@maynard.BSW.COM>, campbell@maynard.BSW.COM (Larry Campbell) writes:
> In article <1987Jan14.123035.20364@sq.uucp> ian@sq.UUCP (Ian F. Darwin) writes:
> >
> >In my humble opinion, the very *existence* of mvdir as separate
> >from the normal mv command is a bug.
> 
> I agree completely.  This, and the implementation of ulimit(2), lead
> me to wonder what AT&T were thinking of when they created S5.  I've
> been trying for three months to convert from V7 to S5;  so far the only
> advantages I can see in S5 are:
> 
>     1)	Greatly improved print spool mechanism (this is indeed a big win)
>     2)	It's a "standard"
> 
	Don't forget:

	a) interprocess communications (truthfully the only thing done REALLY 
	   well in Sys V)

	b) improved cron (everybody gets one)

	c) Minor but useful improvements to lot of utilities.

	d) Depending on the revision you get paging (long overdue)

	e) Much improved terminal library functions (terminfo)

> Against this must be balanced:
> 
>     1)	Above-mentioned bug (yes, bug) in mv

	I don't know about this.  /bin/rm -fr /etc does nasty things too, but
if everything is as it should be, it can only be done by root.  If your 
interested in an O.S. to protect you from yourself, try VMS :-)

>     2)	ulimit (ok, the idea isn't so bad, but the implementation is wrong)
>     3)	adb is missing

	You get sdb instead.  A very good trade.

>     4)	dbm is missing
>     5)	It's bigger and slower
>     6)	The uucp node name is COMPILED into the kernel!
> 
	I agree here!

> If it weren't for the impending arrival (S5R3) of streams and RFS,
> I'd be tempted to give up, buy a source license, and back-port the print
> spool stuff to V7.
> 
> Although I suspect the reasons are political and not technical, I wonder
> if anyone at AT&T (or anyone else who thinks they know the real story)
> could comment on why so much in S5 is missing and/or wrong.


	Its almost impossible to get an entire system now.  You have to
buy a bunch of add-on packages.  I agree, thats a real pain.

			Glenn Sills !houxa!grs

> ...so far the only
> advantages I can see in S5 are:
>	...
> Against this must be balanced:
>	...
>     6)	The uucp node name is COMPILED into the kernel!

	This was true before System V Release 2 (SVR2).
With SVR2 on the 3B2 (I'm not sure about SVR2 on other machines),
one can issue the command

		uname -S new-name

to change the ``UUCP node name'' (it changes the "sysname"
and "nodename" parts of the "utsname" structure in uname(2)).

	Also, as far as just ``UUCP node name'' is concerned
(i.e. the name UUCP calls the local machine when communicating
with a remote machine) this can be changed with the (undocumented)
MYNAME= field in the Permissions file (SVR2 again, or with
HDB UUCP).

			Steve Humphrey
			ihnp4!avalon!merlyn

In article <248@houxa.UUCP> grs@houxa.UUCP (G.SILLS) writes:
>>  3)	adb is missing

>	You get sdb instead.  A very good trade.

I do not think so.  Adb is a very handy tool: sort of the Unix
version of the Swiss Army Knife.  For source code level debugging,
sdb is certainly preferable, but adb can do more.  (Sometimes I
think adb can do anything. :-) )
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu

In article <512@csun.UUCP>, aeusemrs@csun.UUCP (Mike Stump) writes:
> Gee, I though every one knew why they FIXED mv in System V.
> It is a security loophole, isn't it obvious?  (:-)) That is why
> they ONLY allow root to run it in SVR2.
 
> Ok, now to get to the meat of the matter:

<long explanation of an example>

>  it
> is the problem with the person that set up the group write
> priv on d0 that screwed it all up

Yes, but since it is a problem with some administrator screwing things
up then why change the mv command?  The problem would have surely disappeared
by using chmod appropriately, no?  Publicly or Group writeable directories
are certainly asking for trouble in the wrong environment.  

If there is a better explanation of why mvdir was separated out from mv,
I and probably many others are all ears.

>   I agree completely (I hope) that Unix (when
> managed properly) is very secure.

Surely, as good as the next system.  Given the freedom that *can*
be made available under UNIX in the appropriate environments that just *isn't*
available on a lot of other O/S's, its certainly nice to have a 
choice in the matter.
 
> I know this one little article is going to cause an avalanche
> of of articles, but I feel I can say nothing to stop them...

You're probably right.

Ian D.

As quoted from <5152@mimsy.UUCP> by chris@mimsy.UUCP (Chris Torek):
+---------------
| In article <248@houxa.UUCP> grs@houxa.UUCP (G.SILLS) writes:
| >>  3)	adb is missing
| 
| >	You get sdb instead.  A very good trade.
| 
| I do not think so.  Adb is a very handy tool: sort of the Unix
| version of the Swiss Army Knife.  For source code level debugging,
| sdb is certainly preferable, but adb can do more.  (Sometimes I
| think adb can do anything. :-) )
+---------------

Actually, it's not as much a loss as you think; the sys5 version of adb
won't work on non-COFF files.  No more patching of data files or damaged
superblocks, etc.  (BOO, HISS!)

++Brandon
-- 
 ____   ______________
/    \ / __   __   __ \   Brandon S. Allbery	    <backbone>!ncoast!allbery
 ___  | /__> /  \ /  \    aXcess Co., Consulting    ncoast!allbery@Case.CSNET
/   \ | |    `--, `--,    6615 Center St. #A1-105 	   (...@relay.CS.NET)
|     | \__/ \__/ \__/    Mentor, OH 44060-4101     
\____/ \______________/   +1 216 781 6201

As quoted from <402@yabbie.rmit.oz> by rcodi@yabbie.rmit.oz (Ian Donaldson):
+---------------
| If there is a better explanation of why mvdir was separated out from mv,
| I and probably many others are all ears.
+---------------

I was under the impression that it was done for the same reason that rmdir
isn't part of rm.  Under System III, mv could only move a directory from
one name to another if it stayed within the same parent directory.  System
V mv is more general; unfortunately, it now has to deal with `.' and `..'.
Written correctly, mv/mvdir could be used like rm/rmdir by ordinary users.
It is my hope that the separation of the two is a first step in doing this,
the next step being the trapping of illegal situations like that done by
rmdir and rm -r.

++Brandon
-- 
 ____   ______________
/    \ / __   __   __ \   Brandon S. Allbery	    <backbone>!ncoast!allbery
 ___  | /__> /  \ /  \    aXcess Co., Consulting    ncoast!allbery@Case.CSNET
/   \ | |    `--, `--,    6615 Center St. #A1-105 	   (...@relay.CS.NET)
|     | \__/ \__/ \__/    Mentor, OH 44060-4101     
\____/ \______________/   +1 216 781 6201

>I was under the impression that it was done for the same reason that rmdir
>isn't part of rm.

Nope.  "rmdir" and "rm" are both unprivileged commands; "mvdir" is
superuser only.  The only reason I can see why S5 has all that extra
"mvdir" and "mv_dir" baggage is that they *still* haven't implemented
"rename" and didn't want to have "mv" be set-UID root.  Once you've
implemented "rename", any unprivileged program can move directories
around to its heart's content and the system will make sure they
don't snarl up the directory tree.  It is *my* hope that they pick up
"rename" (which is likely, since it's in POSIX) and nuke "mv_dir" and
"mvdir" entirely.

One could make the same argument about "rmdir"; now that there's a
"rmdir" system call (even in S5, with the advent of S5R3), "rmdir"
doesn't need to be privileged.  I don't know why "rm" didn't just
"exec" "rmdir" when it was told to remove a directory, back when
there was no "rmdir" system call; since that was never done, people
may not have bothered folding "rmdir" into "rm" once you didn't have
to be privileged to remove directories.

In article <12301@sun.uucp>, guy@gorodish.UUCP writes:
>[Somebody writes:]
>>I was under the impression that it was done for the same reason that rmdir
>>isn't part of rm.
>
>Nope.  "rmdir" and "rm" are both unprivileged commands...

Careful:  as of this time, for System V this is only true in Release 3.
Earlier releases had no rmdir() syscall; the rmdir program was setuid
root and checked for protections and that the directory was empty except
for . and .. , then used unlink() to delete the victim directory entries
for .  and .. , then the entry in the parent directory itself.
You did out point the SysVR3 restriction later in your posting, to be
fair, but it could be misleading to a reader who only sees the first part
of your posting, which looks like a categorical assertion that System V
per se (the rubric of this newsgroup) needs no privileges for rmdir.

$ uname -a
ttrdc ttrdc 2.0v3 0915 3B-20S
            ^^^^^ (N.B.: Release 2.0 Version 3.  Not Release 3.)

$ ls -l /bin/rmdir
-rwsr-xr-x   1 root     sys         8480 Oct 16  1983 /bin/rmdir
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|            dan levy            |  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,
                                        allegra,ulysses,vax135}!ttrdc!levy