rico@dehn. (Rico Tudor) (10/19/89)
While porting my file archiver from System V to a DECStation 3100, the following questions regarding system calls have arisen: (1) How are permissions set on a symbolic link? (2) How are access & modification times set on a symbolic link? (3) What purpose is served by taking the group ID of a newly created file from the parent directory, rather than the process? In Questions (1) and (2), chmod(2) and utimes(2) follow the link, which I don't want. I am handling Question 1 by temporarily altering the process "umask", but I don't like it. The 3100 runs "Ultrix", a BSD variant.
dm@odin.think.com (Dave Mankins) (10/19/89)
In article <1344@accuvax.nwu.edu> rico@math.nwu.edu (Rico Tudor) writes: >While porting my file archiver from System V to a DECStation 3100, the >following questions regarding system calls have arisen: > (1) How are permissions set on a symbolic link? > (2) How are access & modification times set on a symbolic link? A symbolic link is a way of making another name for a file. The permissions of the linked-to file are the permissions used for every name for the file. This behavior seems surprising until you realize that it is just like hard links. The permissions on the symbolic-link are not used. Symbolic links are just like hard links only with the ability to span filesystems (and, sadly, without the ability to know that, when you remove one name for a file (the target of the symbolic link) there is another name left dangling without a reference). > (3) What purpose is served by taking the group ID of a newly > created file from the parent directory, rather than the > process? Under BSD, a process belongs to many groups at one time. Too bad they didn't do the same thing for files. >In Questions (1) and (2), chmod(2) and utimes(2) follow the link, which I >don't want. I am handling Question 1 by temporarily altering the process >"umask", but I don't like it. The 3100 runs "Ultrix", a BSD variant. I think you'll find that your handling of question 1 actually has no effect on what people can do with the files (symlinks) so created. That is, denying group-write privilege on the symlink, but not the target, will not prevent group-members from writing the file. I am curious, if you're porting this program from System-V, what System-V function are you trying to emulate using symlinks? david mankins (dm@think.com)
chris@mimsy.umd.edu (Chris Torek) (10/19/89)
In article <1344@accuvax.nwu.edu> rico@dehn. (Rico Tudor) writes: > (1) How are permissions set on a symbolic link? They are completely irrelevant---nothing ever uses them. (You can view them with lstat, or `ls -l' [which uses lstat], but the kernel ignores them entirely.) > (2) How are access & modification times set on a symbolic link? As with the permissions, these are irrelevant (only the ctime matters, and only for backups). > (3) What purpose is served by taking the group ID of a newly > created file from the parent directory, rather than the > process? Given that `the process' may be in up to 8 (4.2BSD) or 16 (4.3BSD) groups simultaneously, there is no single correct choice based on the process alone, hence the parent directory rule. -- `They were supposed to be green.' In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz) (10/20/89)
>In article <20258@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: >>In article <1344@accuvax.nwu.edu> rico@dehn. (Rico Tudor) writes: >> (3) What purpose is served by taking the group ID of a newly >> created file from the parent directory, rather than the >> process? > >Given that `the process' may be in up to 8 (4.2BSD) or 16 (4.3BSD) >groups simultaneously, there is no single correct choice based on >the process alone, hence the parent directory rule. Another way of looking at the multi-group capability is that a process has a main/primary group - the one listed in the password file and multiple secondary groups as determined by the group file. It makes sense to me to use the primary group for purposes of file ownership. Directories such as /tmp typically are owned by groups of which users are not members, this has led to surprises at least once for me. Steven M. Schultz sms@wlv.imsd.contel.com
chris@mimsy.umd.edu (Chris Torek) (10/21/89)
In article <38688@wlbr.IMSD.CONTEL.COM> sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz) writes: >Another way of looking at the multi-group capability is that >a process has a main/primary group - the one listed in the >password file and multiple secondary groups as determined by >the group file. The rest of the system disagrees with your interpretation. In fact, the only reason there is a group ID in the password file is because there was one there before, and no one felt like changing the format of /etc/passwd at the time. -- `They were supposed to be green.' In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
barmar@kulla (Barry Margolin) (10/21/89)
In article <38688@wlbr.IMSD.CONTEL.COM> sms@WLV.IMSD.CONTEL.COM.UUCP (Steven M. Schultz) writes: >In article <20258@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: >>Given that `the process' may be in up to 8 (4.2BSD) or 16 (4.3BSD) >>groups simultaneously, there is no single correct choice based on >>the process alone, hence the parent directory rule. > It makes sense to me to use the primary > group for purposes of file ownership. Directories such as /tmp > typically are owned by groups of which users are not members, this > has led to surprises at least once for me. This is presumably why SunOS (and other BSD systems?) supports BOTH types of default group ownership. There's a bit in the directory mode that specifies whether file groups should come from the directory or from the process. /tmp is a good example of a directory whose files should inherit the group from the process (although in most cases /tmp files should probably have null group and world access anyway). But a directory shared by a group of users might want the files to be owned by the group, even though that isn't their primary group. For example, at our site, all regular employees are in primary group "staff", but there are directories whose files should only be writable by users in particular groups. At least the way we use the system, /tmp-style group ownership seems to be in the minority. Spool directories are the only other cases I can think of offhand. There are few other places where users create files in directories owned by groups to which they don't belong (directories tend not to be world-writable -- in fact, were there no other bit available, the world-write bit could have been used as a kludgey way to implement the aforementioned flag). Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
rlk@think.com (Robert Krawitz) (10/22/89)
In article <31003@news.Think.COM>, dm@odin (Dave Mankins) writes:
]Symbolic links are just like hard links only with the ability to span
]filesystems (and, sadly, without the ability to know that, when you remove
]one name for a file (the target of the symbolic link) there is another name
]left dangling without a reference).
I find it more convenient to think of a symlink as nothing more than a
pointer to a named point in the filesystem. A hard link (remember, each
file is really a link) is a pointer to an inode (a filesystem object),
whereas a symlink is a pointer to a name.
--
ames >>>>>>>>> | Robert Krawitz <rlk@think.com> 245 First St.
bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142
harvard >>>>>> . Thinking Machines Corp. (617)876-1111guy@auspex.auspex.com (Guy Harris) (10/22/89)
> Another way of looking at the multi-group capability is that > a process has a main/primary group - the one listed in the > password file and multiple secondary groups as determined by > the group file. It makes sense to me to use the primary > group for purposes of file ownership. The problem is that it may not be a *valid* way of looking at the multi-group capability, in that it doesn't fit reality; there may not be some group that can reasonably act as a user's "primary group". A user might work on several things during a session, and not want to use "newgrp" whenever they change what they're working on to make some different group be their "primary group". > Directories such as /tmp typically are owned by groups of which > users are not members, this has led to surprises at least once > for me. In SunOS 4.x and S5R4, the set-GID bit on a directory specifies whether files created in that directory inherit the group from the parent directory or get it from whatever of a user's groups happens, by chance, to be the group in their password file entry. On such a system, you could turn the set-GID bit off on "/tmp", or get the system administrator to do it....