Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!uunet!uunet.UU.NET!sef
From: mbm@dsbc.icl.co.uk (Malcolm Mladenovic)
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-ID: <1991Jun2.222617.19312@uunet.uu.net>
Date: 2 Jun 91 21:43:18 GMT
Article-I.D.: uunet.1991Jun2.222617.19312
References: <1991Jun2.082051.7235@uunet.uu.net>
Sender: usenet@uunet.uu.net (UseNet News)
Organization: ICL Bracknell, UK
Lines: 64
Approved: sef@uunet.uu.net (Moderator, Sean Eric Fagan - comp.std.unix)
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: mbm@dsbc.icl.co.uk (Malcolm Mladenovic)

In article <1991Jun2.082051.7235@uunet.uu.net> andrew@alice.att.com (Andrew Hume) writes:
>The second problem then arises; in this scenario, one clause says I may read
>and the other says I may not read. How do I break this conflict? Of course, in
>Unix (which after all is only distantly related to 1003.1), the access bits are
>interpreted or enforced as
>	1) if i am the owner, then the owner permissions apply.
>	2) otherwise, if i match the group, then the group permissions apply.
>	3) Otherwise, the other permissions apply.
>But I couldn't find words to that effect in 1003.1.
>
>	Where should I be looking?
>

The sections that define the access permission behaviour are 2.3 and 2.4.
2.3 divides processes between three groups, _file owner class_, _file group
class_ and _file other class_.  These are defined as:

[All quotations are from Draft 13 - I don't have a copy of the standard
itself here, there should be no substantive differnces.]

"A process is in the file owner class of a file if the effective user ID of
the process matches the user ID of the file."

"A process is in the file group class of a file if the the process is not
in the file owner class and if the effective group ID or one of the
supplementary group IDs of the process matches the group ID associated
with the file.  Other members of the class may be implementation defined."

"A process is in the file other class of a file if the process is not
in the file owner class or file group class."


The following appears in section 2.4...

"(1) If the process has appropriate privilege..."
"(2) Otherwise:
 (a) The file permission bits of the file contain read, write, and
 execute/search permissions for the file owner class, file group class,
 and file other class.
 (b) Access is granted if an alternate access control mechanism is not
 enabled and the requested access permission bit is set for the class
 to which the process belongs, or if an alternate access control mechanism is
 enabled and it allows the requested access; otherwise access is denied."

These seem to imply the UNIX System semantics, except that the last sentence
of the definition of file group class seems to permit an implementation to
allow members of the file owner class to be included if the implementation
documents this behaviour.   The definition of file other class does _not_
permit this behaviour.  This would seem rather strange.

Does anyone know if this is the intended interpretation?

>	andrew hume
>	andrew@research.att.com

-Malcolm

-- 
Malcolm Mladenovic				mbm@dsbc.icl.co.uk


Volume-Number: Volume 23, Number 82