gnu@sun.uucp (John Gilmore) (08/15/85)
Eagle!mjs (M.J.Shannon) said: > Lose the data? You mean you'd prefer a copy of a file not to have any of the > attributes of the original? That seems to me to forbid copying of executables > (the non-homogeneous header gets lost in the shuffle, preventing execution of > the copy). Sorry, this *DOES* violate "the UNIX way of storing files". Unix is not pristine about this either. Why do you have to copy executables with "cp" rather than "cat" or "dd"? They won't execute if you cat them...because the file permissions ("attributes" of the original) are specifically propagated by code in "cp", but not by "cat". I have no doubt that adding MORE attributes would break existing Unix utilities -- but I don't think that was the point of view expressed.
peter@baylor.UUCP (Peter da Silva) (08/19/85)
> Unix is not pristine about this either. Why do you have to copy > executables with "cp" rather than "cat" or "dd"? They won't execute if > you cat them...because the file permissions ("attributes" of the > original) are specifically propagated by code in "cp", but not by > "cat". Yeh, executability should perhaps be handled by a magic number. Of course this would break shell scripts, but that's been done before. Of course it IS easier to type 'chmod +x file' than to reconstruct the header... -- Peter da Silva (the mad Australian werewolf) UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076
thau@h-sc1.UUCP (robert thau) (08/21/85)
> Yeh, executability should perhaps be handled by a magic number. Of course this > would break shell scripts, but that's been done before. Of course it IS easier > to type 'chmod +x file' than to reconstruct the header... > -- > Peter da Silva (the mad Australian werewolf) One thing to keep in mind: execute-only privilege. The only real reason for it that I can think of is spoiler-hiding for adventure games, but it seems that *somebody* wants it. (Opinion: any security scheme which depends critically on withholding the code that implements it has failed before it starts). -- Robert Thau \ Keeper of the *FLAME* )) rst@tardis.ARPA ( ( h-sc1%thau@harvard.ARPA \\
arnold@ucsfcgl.UUCP (Ken Arnold%CGL) (08/23/85)
In article <2636@sun.uucp> gnu@sun.uucp (John Gilmore) writes: >Why do you have to copy >executables with "cp" rather than "cat" or "dd"? They won't execute if >you cat them...because the file permissions are specifically propagated >by code in "cp", but not by "cat". To copy files with cp you say "cp file1 file2". To copy files with cat you say "cat file1 > file2". If you look carefully, you will note that cat does not copy files. That is not its function. The ">" part of the command is executed by the shell, which is simply putting the output of whatever command is to the left of the ">" into the file named on the right. It doesn't know that you're trying to do a copy. What permissions should be set "make.out" given make >& make.out ? Does it need execute permissions? You're asking for dwim, here. "cp" is to copy files. "cat" is to concatentate them and print them. That there are many ways to do almost anything in UNIX, but this does not relieve you of the responsibility of using wrong ones. "dd", of course, does claim to copy files, but it was really designed for moving files to and from devices, not just copying one file to another, so you might look somewhat kindly on the people who left it out. Ken Arnold
ed@mtxinu.UUCP (Ed Gould) (08/24/85)
In article <2636@sun.uucp> gnu@sun.uucp (John Gilmore) writes: >Unix is not pristine about this either. Why do you have to copy >executables with "cp" rather than "cat" or "dd"? They won't execute if >you cat them...because the file permissions ("attributes" of the >original) are specifically propagated by code in "cp", but not by >"cat". The reason is that cp is the utility to copy files. Neither cat nor dd is, even though it's possible to use them to make copies. Cat takes named files and/or standard input and places the catenation of them on standard output. Dd is a data manipulation program. There's no reason to assume that what comes out of either has any obvious relation to an executable that goes in. -- Ed Gould mt Xinu, 2910 Seventh St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."
jqj@cornell.UUCP (J Q Johnson) (08/26/85)
In article <452@mtxinu.UUCP> ed@mtxinu.UUCP (Ed Gould) writes: >>...Why do you have to copy >>executables with "cp" rather than "cat" or "dd"? > >The reason is that cp is the utility to copy files. . . . Precisely. A special utility is needed because files are not the same things as pipes or devices (yes, I'd like to be able to do things like ``exec("/dev/ttyh3")'' to upload a program from my micro!). One way in which they differ is that they have some special attributes. Not many, and the list of attributes is not user-extensible.
tanner@ki4pv.UUCP (Tanner Andrews) (08/27/85)
] ... execute only privilege ... only reason is spolier-hiding ... games There is one other reason for this -- prevention of rampant copies of assorted progs. Old versions of things for which people have a fondness are bad enough. People make copies of games so that they may be played during busy times; execute-only prevents this. -- <std dsclm, copies upon request> Tanner Andrews, KI4PV uucp: ...!decvax!ucf-cs!ki4pv!tanner
john@basser.oz (John Mackin) (08/30/85)
In article <547@h-sc1.UUCP> thau@h-sc1.UUCP (robert thau) writes: > One thing to keep in mind: execute-only privilege. The only real reason for > it that I can think of is spoiler-hiding for adventure games, No, there is an excellent reason for it. If you keep your executables in /bin and such places execute-only, your users can't copy them (don't ask me why they WANT to copy them, but I can assure you they do -- at least ours do). You get proliferation of versions if they do it. You install a new version of whatever and people complain about bugs you thought you'd fixed, and they turn out to be running a private copy of the old version. Annoying, to say the least, as well as a waste of disk space. John Mackin, Basser Department of Computer Science, University of Sydney, Sydney, Australia UUCP: ...!decvax!mulga!basser.oz!john ...!seismo!munnari!basser.oz!john (faster) ARPA: munnari!basser.oz!john@SEISMO.CSS.GOV