allbery@ncoast.UUCP (Brandon Allbery) (10/23/86)
Quoted from <1060@cit-vax.Caltech.Edu> ["Re: Use of ``vi'' for business office word-processing"], by mangler@cit-vax.Caltech.Edu (System Mangler)... +--------------- | In article <810@aimmi.UUCP>, gilbert@aimmi.UUCP (Gilbert Cockton) writes: | > I'd be curious to see how many people see computer file space as personal | > space into which no-one should intrude, regardless of access permissions. | | The policy on our student machine is: | "Do not read other people's files without explicit permission." | | where "explicit" means "they specifically told you that you could look". +--------------- I see a computer file system as no different from a regular file cabinet which has a potential for access by "ordinary people". If a file isn't marked as private, or a file drawer is locked (equivalent: file system access permission denies access to the user/group/account/etc.), people shouldn't look. But if a file (file folder) isn't protected or marked as private, there's no reason for someone NOT to look at it. This is true for a file cabinet OR a file system. Caveat filer. My personal practice is that I lock files I don't want people snooping in or around, and leave files readable by others if I want them to look. I also have a directory ".transfer" in my home directory which is writeable by all, so a user can send me files. (I have csh aliases "lock" and "unlock", plus a program to examine files in a particular directory -- a shell script "scan" which uses the "file" command to figure out whether a file is ASCII, binary, a subdirectory, etc. and uses the appropriate command to look at it (more, strings, resursive "scan", etc.).) However, the other view is permissible by this as well: the customer file cabinet at TDI is unlocked, but I have no business snooping in it. This is a matter of policy (office file policy/computer file policy). In the end, it comes down to a management decision. My file policy on ncoast is consistent with ncoast's policy as a public-access system; at TDI, it is necessarily different and more in step with TDI office policy. ++Brandon -- ---------------- /--/ Brandon S. Allbery UUCP: decvax!cwruecmp! / / /|\/ Tridelta Industries, Inc. ncoast!tdi2!brandon ---- -------- /-++ 7350 Corporate Blvd. PHONE: +1 216 974 9210 / / /---, ---- Mentor, Ohio 44060 SYSOP: UNaXcess/ncoast / / / / / / -- HOME -- (216) 781-6201 24 hrs. / / / / / / 6615 Center St. Apt. A1-105 ARPA: ncoast!allbery% ---- -----~ ---- Mentor, Ohio 44060-4101 case.CSNET@relay.cs.net
thomps@gitpyr.gatech.EDU (Ken Thompson) (10/25/86)
The discussion about whether or not it is morally acceptable to
read another person's unprotected files has made one thing perfectly
clear : You had better protect your files if you don't want other people
to read them because a lot of people will. As an administrator of a small
Unix system (about 12 users), I always explain this to new users. Assume
that someone will read your files if they are left accessible.
As far as the moral question goes, it seems to have something
to do with violating a person's physical space. People seem to think much
longer before going into a colleagues file cabinet than they do about looking
at the same colleagues unprotected files. I think this has to do with the
physical aspect of entering an office and opening a file cabinet.
Somehow, a cd and a cat just doesn't seem the same. I am not really
arguing that there is a moral distinction, just speculating on what makes
so many people believe there is.
--
Ken Thompson Phone : (404) 894-7089
Georgia Tech Research Institute
Georgia Insitute of Technology, Atlanta Georgia, 30332
...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!thompsthomps@gitpyr.gatech.EDU (Ken Thompson) (10/25/86)
References: <115@tijc02.UUCP> <735@hropus.UUCP> <1040@ho95e.UUCP> <1618@ncoast.UUCP> > It *might* be possible to run "lp" setgid only -- but that might not help > you. (Although it would take strange circumstances to do that.) But "lp" > revolves around a few special files in /usr/spool/lp and ordinary users > shouldn't be allowed to muck with them; even if they know what they're doing, > mucking with /usr/spool/lp/outputq while lpsched is running is a good way > to trash the print queue. > I still find it irritating and so do my user's when I can cat a file to the screen but can't print it using lp. On our system we have a shell script which does a cat on a file and pipes it to lp to get around the problem. Somehow though it seems like it shouldn't be this way. Alas, I fear it is a limitation of the rather. -- Ken Thompson Phone : (404) 894-7089 Georgia Tech Research Institute Georgia Insitute of Technology, Atlanta Georgia, 30332 ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!thomps