🚀 go-pugleaf

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

Submitted-by: ed@mtxinu.COM (Ed Gould)

>The problem, phrased in 1003.1's terms, is what happens if i am both
>the owner and group of a file with mode 040; can I read it?

The traditional UNIX implementation of file permissions has
been

	if owned by user
		check owner bits
	else if owned by user's group
		check group bits
	else
		check other bits

Hence, if one owns a file *only* the owner bits matter.  The group
bits apply only to non-owners in the group; the other bits apply
only to non-owner non-group.  I don't know what 1003.1 says, though.
Given its reliance on traditional UNIX, this is what I'd expect it
to say.

The other reasonable interpretation I can imagine is

	if (owned by user and owner bits allow access) or
	   (owned by user's group and group bits allow access) or
	   (other bits allow access)
		grant access
	else
		deny access

I'd bet small amounts of money that this latter interpretation
doesn't conform to 1003.1.

-- 
Ed Gould			No longer formally affiliated with,
ed@mtxinu.COM			and certainly not speaking for, mt Xinu.

"I'll fight them as a woman, not a lady.  I'll fight them as an engineer."


Volume-Number: Volume 23, Number 83

Submitted-by: decot@hpcupt1.cup.hp.com (Dave Decot)

>> HP solved this, I believe (at least, according to an article in _The Journal
>> of C Language Translation_).  I looked into this, way back when I was
>> involved with development system work, and came up with a couple of
>> solutions, at least one of which will likely be used.  (They're both fairly
>> obvious.)
> 
> HP is *already* claiming Posix compliance, and you say one of the
> solutions "will likely be used".  *That* is precisely the problem.
> 
> 	-mib

Well, it's not a problem in HP's case.  HP first released POSIX.1 conformance
(and XPG3 and ANSI C conformance) in HP-UX 7.0 (completed in November of 1989).

That release included support for secondary definitions as described in the
referenced JoCLT article, and used it to prevent link-time namespace pollution.

I believe that "will be used" was referring to the poster's own system,
not HP-UX.

Dave Decot, HP
Disclaimer: my opinions only.


Volume-Number: Volume 24, Number 12