aeusesef@csun.UUCP (08/18/87)
[Aren't you glad there's no more line-eat
While playing with an AT&T SystemV 2.0 Unix, I made a little file
with access mode 0446 (r--r--rw-), and tried to write into it.
Surprise! The kernal said I couldn't. I understand what it's doing,
but what I want to know is if the rest of the world considers this a bug, a
feature, or something which doesn't matter.
(A friend suggested putting code in the kernal for creat, chmod, etc. so
that this type of mode wouldn't happen; I disagree about this type of
kludge.)
I would appreciate any input on this subject.
(*I* think it's a bug, but then I'm only a lowly student who isn't allowed
to look at source code 8-))
-----
Sean Eric Fagan Office of Computing/Communications Resources
(213) 852 5742 Suite 2600
1GTLSEF@CALSTATE.BITNET 5670 Wilshire Boulevard
Los Angeles, CA 90036
{litvax, rdlvax, psivax, hplabs, ihnp4}!csun!{aeusesef,titan!eectrsef}
#include <std-disclaim.t>
#include <.signature.t>mwp@munnari.oz (Michael W. Paddon) (08/19/87)
in article <719@csun.UUCP>, aeusesef@csun.UUCP (Sean Eric Fagan) says: > > While playing with an AT&T SystemV 2.0 Unix, I made a little file > with access mode 0446 (r--r--rw-), and tried to write into it. > Surprise! The kernal said I couldn't. I understand what it's doing, > but what I want to know is if the rest of the world considers this a bug, a > feature, or something which doesn't matter. > > (A friend suggested putting code in the kernal for creat, chmod, etc. so > that this type of mode wouldn't happen; I disagree about this type of > kludge.) This is *not* a bug. You created a file with write permission denied to the owner (that's you). Suprise! The kernel would have (rightly so) given "permission denied" or some such error. The 07 mode bits on a file refer to everyone but the owner and those users in the file's group not, as some people assume, *everbody*. Have a look at the stat(2) manual entry. This has nothing to do with where the code is situated, kernel or not. Note that the calls you mention are already in the kernel anyway and that all possible file modes are legal (in the 07777 range anyway). Michael Paddon ============== =========================== UUCP: {seismo,mcvax,ukc,ubc-vision}!munnari!mwp ARPA: mwp%munnari.oz@seismo.css.gov CSNET: mwp%munnari.oz@australia
guy%gorodish@Sun.COM (Guy Harris) (08/19/87)
> While playing with an AT&T SystemV 2.0 Unix, I made a little file > with access mode 0446 (r--r--rw-), and tried to write into it. > Surprise! The kernal said I couldn't. I understand what it's doing, > but what I want to know is if the rest of the world considers this a bug, a > feature, or something which doesn't matter. I consider it to be, at worst, something that doesn't matter, and at best a feature. The only reason why you'd *want* to give a file modes like that is, presumably, that you really *do* want to permit people not the owner of the file and not in the group that owns the file to write it, but to forbid the owner and people in the group that owns it to write it. It's not really the system's job to say "that doesn't make sense" and override your judgement. > (A friend suggested putting code in the kernal for creat, chmod, etc. so > that this type of mode wouldn't happen; I disagree about this type of > kludge.) Yes. Again, it shouldn't be the system's job to enforce policy. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
rick@seismo.CSS.GOV (Rick Adams) (08/20/87)
It is clearly a feature, and a useful one at that. Consider that you have a public ftp directory which anyone can access via anonymous ftp. You want to have the normal users on your system be able to put files into ~ftp, but you don't want to let the "anonymous" user be able to write or delete files in that directory. The simple solution is to make the directory mode 577 owned by ftp. It works. ---rick
gwyn@brl-smoke.ARPA (Doug Gwyn ) (08/20/87)
In article <719@csun.UUCP> aeusesef@csun.UUCP (Sean Eric Fagan) writes: >While playing with an AT&T SystemV 2.0 Unix, I made a little file >with access mode 0446 (r--r--rw-), and tried to write into it. >Surprise! The kernal said I couldn't... No surprise at all; that's how it is intended to work. Please do not muck around with it.
davy@ea.ecn.purdue.edu (Dave Curry) (08/20/87)
In article <719@csun.UUCP> aeusesef@csun.UUCP (Sean Eric Fagan) writes: >While playing with an AT&T SystemV 2.0 Unix, I made a little file >with access mode 0446 (r--r--rw-), and tried to write into it. >Surprise! The kernal said I couldn't. No surprise. The three sets of permissions on a file are: - permissions for the owner of the file, - permissions for other members of the file's group, EXCLUDING the owner, and - permissions for other users of the system EXCLUDING the owner and members of the file's group. These permissions are applied by the kernel in a left to right order until they match. I.e., if you own the file, the first set of permissions apply. If you do not own the file, but are a member of the group, the second set applies. If you are not the owner and not in the group, only then does the third set apply. Since you own the file, the set of permissions applied to you are the owner permissions, which do not include permission to write. >(A friend suggested putting code in the kernal for creat, chmod, etc. so >that this type of mode wouldn't happen; I disagree about this type of >kludge.) Please ask your friend to stay away from the kernel until he knows what he's doing. There are perfectly valid uses for permisssions like this, such as preventing a given group of people from doing things to a file, and so on. >(*I* think it's a bug, but then I'm only a lowly student who isn't allowed >to look at source code 8-)) It most certainly is NOT a bug. If the kernel had allowed you to write the file when world-write was on and owner-write was off, then what would be the point of having owner permissions at all? As a more useful example, consider the group permissions - if the world permissions allowed write to everyone as under your scheme, there would be no way to PREVENT a given group of people from writing the file (since group permissions would be meaningless). Under the current scheme, you can do this. --Dave Curry Purdue University
aeusesef@csun.UUCP (Sean Eric Fagan) (08/21/87)
In article <366@ea.ecn.purdue.edu> davy@ea.ecn.purdue.edu.UUCP (Dave Curry) writes: >In article <719@csun.UUCP> aeusesef@csun.UUCP (Sean Eric Fagan) writes: [I say some stuff] >No surprise. The three sets of permissions on a file are: > > - permissions for the owner of the file, > - permissions for other members of the file's group, > EXCLUDING the owner, and > - permissions for other users of the system EXCLUDING > the owner and members of the file's group. Ok, I wasn't too positive about all of the finer points (sue me, I'm ignorant). Anyway, I understand all of this now, and I appreciate all of the people who took time to respond (even the ones who implied that I was incredibly stupid). I just wasn't aware that each set of permissions excluded the others, but it does make a lot of sense now that I think about it. Thanks muchly. Sean Eric Fagan Office of Computing/Communications Resources (213) 852 5742 Suite 2600 1GTLSEF@CALSTATE.BITNET 5670 Wilshire Boulevard Los Angeles, CA 90036 {litvax, rdlvax, psivax, hplabs, ihnp4}!csun!{aeusesef,titan!eectrsef}