HOLSTEGE@Cit-20@sri-unix (08/28/82)
Date: 23 Aug 1982 1448-PDT One reason for not allowing users to chown their files is that tar, at least on UNIX-TS, attempts to chown the files it extracts from tape to their original owner. Needless to say, if you are transferring from one machine to another, this is disaster. You wind up making a directory tree owned by someone else, possibly a non-existent someone else. Worse, usually the directories are mode 755, so you can't even delete any of it. All you can do is get the superuser to fix it all. This makes tar pretty painful for moving software from one machine to another. -------
jensen (08/31/82)
I don't think that the problem with tar attempting to chown files (a problem which could be fixed in no time by making it an option) is sufficient to end the whole debate about allowing users to chown their files. Daniel Jensen sri-unix!fortune!jensen
HOLSTEGE@Cit-20@sri-unix (09/04/82)
Date: 31 Aug 1982 1321-PDT Alan Watt points out that the point of being able to chown a file is to transfer control of that file from one user to another. I feel that this should not be possible wothout the conset of BOTH of the involved users; in this case "cp" is entirely suitable. Thus chown should be restricted. -------
gwyn@Brl@sri-unix (09/04/82)
From: Doug Gwyn <gwyn@Brl> Date: 31 Aug 82 0:59:02-EDT (Tue) It was my impression that "tar" would only chown files it was restoring to the file system when run by the super-user. A normal user should still end up owning all the files restored. (If "tar" doesn't work this way, then maybe it needs to be changed to do so.)
gwyn@Brl@sri-unix (09/04/82)
From: Doug Gwyn <gwyn@Brl> Date: 31 Aug 82 1:03:27-EDT (Tue) I'm also in favor of a liberal chown(), but there IS a difference between a file's original owner putting it into someone else's quota without his knowledge or consent vs. the other person grabbing a copy of the file (perhaps via linking, perhaps a real copy) if you let him access it.
gwyn@Brl@sri-unix (09/04/82)
From: Doug Gwyn <gwyn@Brl> Date: 31 Aug 82 2:22:50-EDT (Tue) Users can cooperate to transfer a file via e.g. $ mkdir /tmp/x $ cp myfile /tmp/x/yourfile $ chmod 700 /tmp/x/yourfile $ chown you /tmp/x/yourfile $ chmod 755 /tmp/x $ mail you Ok, it's in /tmp/x. Mail me a note when you have it. (later...) $ rm -rf /tmp/x The advantage of this is that you don't have to give any more access to the other fellow than you intended (your login directory can still be private, for example). Also, I think it's foolproof since you aren't going to remove it until you know that it has been received.
gwyn@Brl@sri-unix (09/07/82)
From: Doug Gwyn <gwyn@Brl> Date: 4 Sep 82 23:11:01-EDT (Sat) Direct use of "cp" would give access to more people than just the two parties involved. Something more elaborate is called for.
mark (09/08/82)
Users exchanging files is not hard, even when the system bends over backwards to prevent it. At Berkeley, many of the Computer Center systems run the "fascist file system" which does not permit "class users" (uid < 0) to access each others files even if the permissions indicate they should be able to. (I may be out of date here.) When students REALLY wanted to exchange programs, they would just mail them to each other. Of course, this doesn't work for binaries, but you can always uuencode the binary. Another technique is to uucp or netcp them to the other user, possibly having to resort to an intermediate system.
jis (09/08/82)
I have always wondered why tar did not provide an option that would suppress chowning extracted files to the ownership of the original owner, who more often than not does not exist on the system, (or worse is someone else!). I do not think disallowing chown is a solution to this problem at all! Jishnu Mukerji Bell Laboratories HO 1B-425 (201) 949-3427 harpo!hocsd!jis
larry@utecfa.UUCP (Larry Philps) (07/02/85)
Subject: chown(1) / chgrp(1) do not work on symbolic links
Index: /usr/src/bin/chgrp.c /usr/src/etc/chown.c 4.2BSD
Description:
The chown system call does not follow symbolic links in
namei so that it is possible to change the owner and group
of the link itself and not just what it points to. Also
chown(2) changes both the owner and group. Thus chown (1)
stat's the destination file in order to find its current group.
This value is then used in the call to chown (2). A similar
situtation exists for chgrp in which it needs to know the current
owner of the file before calling chown (2). However, both
chgrp and chown use the stat (2) system call, so that if you
try to chown/chgrp a symbolic link, the group/owner will end up
being set to the group/owner of the file the link points to.
Repeat-By:
Script started on Tue Jul 2 13:35:55 1985
# echo > junk
# chown 9998 junk
# chgrp 9999 junk
# ln -s junk symlink
# ls -lg symlink junk
-rw-r--r-- 1 9998 9999 0 Jul 2 13:36 junk
lrwxr-xr-x 1 0 0 4 Jul 2 13:36 symlink@ -> junk
# chown root symlink
# ls -lg junk symlink
-rw-r--r-- 1 9998 9999 0 Jul 2 13:36 junk
lrwxr-xr-x 1 0 9999 4 Jul 2 13:36 symlink@ -> junk
----
# rm symlink
# ln -s junk symlink
# ls -lg symlink junk
-rw-r--r-- 1 9998 9999 0 Jul 2 13:36 junk
lrwxr-xr-x 1 0 0 4 Jul 2 13:36 symlink@ -> junk
# chgrp daemon symlink
# lg -lg junk symlink
-rw-r--r-- 1 9998 9999 0 Jul 2 13:36 junk
lrwxr-xr-x 1 9998 1 4 Jul 2 13:37 symlink@ -> junk
----
Fix:
Change the call to stat (2) in both chgrp.c and chown.c to be
a call to lstat (2).
*** /tmp/,RCSt1001285 Tue Jul 2 13:43:07 1985
--- chown.c Tue Jul 2 11:29:46 1985
***************
*** 41,45
cho:
for(c=2; c<argc; c++) {
! stat(argv[c], &stbuf);
if(chown(argv[c], uid, stbuf.st_gid) < 0 && !fflag) {
perror(argv[c]);
--- 45,49 -----
cho:
for(c=2; c<argc; c++) {
! lstat(argv[c], &stbuf);
if(chown(argv[c], uid, stbuf.st_gid) < 0 && !fflag) {
perror(argv[c]);
*** /tmp/,RCSt1001291 Tue Jul 2 13:43:23 1985
--- chgrp.c Tue Jul 2 11:32:33 1985
***************
*** 71,75
ok:
for (c = 1; c < argc; c++) {
! if (stat(argv[c], &stbuf)) {
perror(argv[c]);
continue;
--- 72,76 -----
ok:
for (c = 1; c < argc; c++) {
! if (lstat(argv[c], &stbuf)) {
perror(argv[c]);
continue;
--
Larry Philps
Engineering Computing Facility
University of Toronto
{linus,ihnp4,uw-beaver,floyd,decvax,utzoo}!utcsri!utecfa!larry