cc1@valhalla.cs.ucla.edu (09/13/88)
Now for the $64 question:
Way back in V7, there was a command mv, and a command ln, and a command cp.
All three were different. mv would let you move any file around the
file system regardless of what type it was.
Now comes sys5. mv, cp, and ln are the same program (Why?).
mv will let you move a file around, but requires a directory to stay in the
same parent directory.
Why?
A program called "mvdir" was added, that lets you move a directory around
the file system.
Why the seperate program?
Now,
***** mvdir was NOT included on the 3b1 *****
Why not? WHere can I get it?
Now, its not the absolute end of the world. I can put in ~/bin the
following little thing
main(argc,argv) char **argv;
{
link (argv[1], argv[2]);
unlink (argv[1]);
}
, add some checks, and make it 6777, owned by root, in a directory only
I can use, but still, why?
Michaelscl@virginia.acc.virginia.edu (Steve Losen) (09/13/88)
In article <15911@shemp.CS.UCLA.EDU> cc1@CS.UCLA.EDU (Michael Gersten) writes: >Now, its not the absolute end of the world. I can put in ~/bin the >following little thing > >main(argc,argv) char **argv; >{ > link (argv[1], argv[2]); > unlink (argv[1]); >} > >, add some checks, and make it 6777, owned by root, in a directory only >I can use, but still, why? > > Michael Moving a directory around takes a little more effort than the folks at AT&T were willing to put forth, I suppose. Besides just moving the the directory itself, you must fix its ".." entry. Another problem is that you must be root to link/unlink a directory and we all know what gaping security problems setuid to root programs can cause. You also don't want to allow people to do things like "mv . foo" or "mv .. foo" (or "mv x/. foo" for that matter) or you'll lose . and .. entries. Furthermore, you can't allow a directory to be moved into its own subtree or you'll disconnect it from the file system, i.e., mv x x/y I have modified mv/cp/ln and /usr/lib/mv_dir to correctly move directories. (not just rename them) If anyone with an AT&T sysV source licence wants it, I'll be happy to give it to you. I've also implemented the Berkeley "-i" option that asks for confirmation before clobbering an existing file. -- Steve Losen scl@virginia.edu University of Virginia Academic Computing Center
cc1@valhalla.cs.ucla.edu (Michael Gersten) (09/14/88)
In article <1050@virginia.acc.virginia.edu> scl@virginia.acc.Virginia.EDU (Steve Losen) writes: >In article <15911@shemp.CS.UCLA.EDU> cc1@CS.UCLA.EDU (Michael Gersten) writes: >> [a ten line program to move a file deleted] > >Moving a directory around takes a little more effort than the folks at >AT&T were willing to put forth, I suppose. Besides just moving the >the directory itself, you must fix its ".." entry. Another problem is > [...] Well, thats not my point. Yes, I did miss some obvious problems with my little "mv" program. BUT A) The code was in mv way back in V7, and probably V6. B) Sys 3 and sys 5 machines normally have a "mvdir" program that does this. C) In the 18 pages of "How the 3b1 differs from 5.2", we see: mvdir: This command exists for 5.2 but is not on the 3b1. We also see the same thing for "at". Now for the $128 question: Does anyone have a copy of "at" and "atrun" that they can give out for the 3b1? >I have modified mv/cp/ln and /usr/lib/mv_dir to correctly move >directories. (not just rename them) If anyone with an AT&T sysV source >licence wants it, I'll be happy to give it to you. I've also >implemented the Berkeley "-i" option that asks for confirmation before >clobbering an existing file. Tell ya what: I have a binary license, so could you give me the binaries? Michael
paddock@mybest.UUCP (Steve Paddock) (09/16/88)
In article <15945@shemp.CS.UCLA.EDU> cc1@cs.ucla.edu (Michael Gersten) writes: > >Now for the $128 question: Does anyone have a copy of "at" and "atrun" that >they can give out for the 3b1? > No, not unless you have a source license :-), however for the record mvdir is a shell script on the 3B2. -- ------------------------------------------------------------------------------ Steve Paddock uunet!bigtex!mybest!paddock ut-emx!mybest!paddock {attmail|gbsic5|bscaus}!uhous1!paddock
jbm@uncle.UUCP (John B. Milton) (09/17/88)
In article <15911@shemp.CS.UCLA.EDU> cc1@CS.UCLA.EDU (Michael Gersten) writes: ... >***** mvdir was NOT included on the 3b1 ***** >Why not? WHere can I get it? >Now, its not the absolute end of the world. I can put in ~/bin the >following little thing > >main(argc,argv) char **argv; >{ > link (argv[1], argv[2]); > unlink (argv[1]); >} > >, add some checks, and make it 6777, owned by root, in a directory only 6777, now really! You need to think about the . and .. entries. You need to think about what happens to ANY process using any of the involved directories (open or as PWD). It is not as trivial as it sounds. SYSV DOES NOT LIKE to have . and .. out of whack ever. It may work for you and crash another system. The safe way to move a directory tree in SYSV is to use: find . -print|cpio -p dir read up on the -p to get the flavor right John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu home: (614) 294-4823, work: (614) 459-7641; CP/M to MP/M, MS-DOS to OS/2
david@ms.uky.edu (David Herron -- One of the vertebrae) (09/19/88)
If mvdir is so dangerous then why do 'real' SysV's have it and the
Unix PC ones don't? I've always heard people attribute this to
someone being afraid that the original target audience for these
machines (the 'novice' types) would do something to screw up the
system and not be able to recover.
Sigh
--
<---- David Herron -- One of the MMDF guys <david@ms.uky.edu>
<---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<---- What does the phrase "Don't work too hard"
<---- have to do with the decline of the american 'work ethic'?cc1@valhalla.cs.ucla.edu (Michael Gersten) (09/22/88)
In article <15911@shemp.CS.UCLA.EDU> I was talking about mvdir not on the 3b1, and proposed the following little program in a protected directory: >> >>main(argc,argv) char **argv; >>{ >> link (argv[1], argv[2]); >> unlink (argv[1]); >>} >> >>, add some checks, and make it 6777, owned by root, in a directory only Now, I got a few comments, about other references to the directory, ., .. of children, etc. So, I decided to figure them out. If you spot any errors, please let me know. First: mymvdir dir1 dir2 (renaming in the current directory) mymvdir will link the two, then unlink the first. This will result in an extra link count for the inode initially, then a normal link count. The id inode has not changed, so dir1/*/.. (now dir2/*/..) has the correct inode number. Second: mymvdir dir1 dir2/dir1 (putting into a sub directory) Once again, the inode in use will be the same. Therefore, any ..'s, .'s, or others will still have the correct inode number. Third: mymvdir dir1 dir1/dir2 This will cause problems. After dir1 is unlinked, there will be no file for that inode/directory that can be referenced. Fourth: current directories. As I understand it, a process's current directory is just the inode number of the directory, and the disk sectors are read in from the buffer pool as needed. Since the inodes are still the same, and directory writes (since the names have been changed) go into the buffer pool immediately, this should not be a problem. Bottom line: I have spent 3 days poking at this, and can find no problem other than security, or if the user makes a mistake. So, can anyone tell me why I should not make this availible for myself? Michael Still looking for a real "mvdir", "at", and "atrun", as well as a good mv that mv's dir on its own.
randy@umn-cs.CS.UMN.EDU (Randy Orrison) (09/22/88)
In article <16129@shemp.CS.UCLA.EDU> cc1@cs.ucla.edu (Michael Gersten) writes: |First: mymvdir dir1 dir2 (renaming in the current directory) |mymvdir will link the two, then unlink the first. This will result in an |extra link count for the inode initially, then a normal link count. The id |inode has not changed, so dir1/*/.. (now dir2/*/..) has the correct inode number. Ok. |Second: mymvdir dir1 dir2/dir1 (putting into a sub directory) |Once again, the inode in use will be the same. Therefore, any ..'s, .'s, or |others will still have the correct inode number. No, the '..' entry in dir1 will have to be changed from whatever it was to dir2, otherwise doing 'cd ..' from dir1 after this will put you in dir1's old parent. |Third: mymvdir dir1 dir1/dir2 |This will cause problems. After dir1 is unlinked, there will be no file for that |inode/directory that can be referenced. Simple to solve, though: don't allow it. Remember to check for aliases, though. (e.g. mv dir1 ../dir1/dir2) |Fourth: current directories. |As I understand it, a process's current directory is just the inode number |of the directory, and the disk sectors are read in from the buffer pool as |needed. Since the inodes are still the same, and directory writes (since the |names have been changed) go into the buffer pool immediately, this should not |be a problem. I'm not sure about this. |Bottom line: I have spent 3 days poking at this, and can find no problem other |than security, or if the user makes a mistake. So, can anyone tell me why I |should not make this availible for myself? For yourself: go ahead, it's your system. You're the one that will have to fix it if anything goes wrong. I looked at #2 above for a couple seconds and found a problem you missed. I certainly wouldn't expect there not to be any more. -randy