andrew@alice.att.com (Andrew Hume) (06/02/91)
Submitted-by: andrew@alice.att.com (Andrew Hume) While casually reading ISO 9660, I happened across the file permissions field for a file. This is some twisted person's idea of a joke but probably is the VMS permissions field. What was not specified was what happens if two different bits conflict (more on what i mean exactly below). ``Ha!!'', I said, ``1003.1 would have gotten that right!'' Unfortunately, I couldn't find the explanation in 1003.1. Can someone help me out here? 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? There are actually two problems. One is that 1003.1 defines bits and mentions words like read permission and masks but never actually says what the meaning of S_IRUSR (for example) is when it is set (or not). But let us pass over that and assume the wording should have been something like: If S_IRUSR is set, then the user whose ID == st_uid may read the file. If S_IRUSR is not set, then the user whose ID == st_uid may not read the file. 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? andrew hume andrew@research.att.com Volume-Number: Volume 23, Number 81
mbm@dsbc.icl.co.uk (Malcolm Mladenovic) (06/03/91)
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
clive@x.co.uk (Clive Feather) (06/03/91)
Submitted-by: clive@x.co.uk (Clive Feather) > 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? In 2.4 (file access permissions) it reads in part: "The file permission bits of a file contain read, write, and execute/search permissions for the file owner class, file group class, and file other class". > There are actually two problems. One is that 1003.1 defines bits and > mentions words like read permission and masks but never actually says > what the meaning of S_IRUSR (for example) is when it is set (or not). In 5.6.1.2: "S_IRUSR read permission bit for the file owner class" etc. So, your file (040) has read permission for the file group class, but not the file owner class. Now we go to the definitions in 2.3: "file owner class: 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." "file group class: a process is in the file owner class of a file if the process is not in the file owner class and if the effective group ID ... of the process matches the group ID associated with the file." The owner of the file is never in the file's group class, and so only the first 3 permission bits matter. Which is what you would expect. Finally, B.2.3 says "Note that a process is in one and only one class, so there is no ambiguity." > But let us pass over that and assume the wording should have been > something like: Let us not. Let us RTFS instead. -- Clive D.W. Feather | IXI Limited | If you lie to the compiler, clive@x.co.uk | 62-74 Burleigh St. | it will get its revenge. Phone: +44 223 462 131 | Cambridge CB1 1OJ | - Henry Spencer (USA: 1 800 XDESK 57) | United Kingdom | Volume-Number: Volume 23, Number 84
ed@mtxinu.COM (Ed Gould) (06/03/91)
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
mib@geech.gnu.ai.mit.edu (Michael I Bushnell) (06/04/91)
Submitted-by: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
In article <1991Jun3.192534.28089@uunet.uu.net> clive@x.co.uk (Clive Feather) writes:
Let us not. Let us RTFS instead.
Sigh. RTFS, of course, stands for Read The Source. Which, of course,
is the way these kinds of issues were once handled in Unix-land.
Later came "experiment", which also confirms the Posix method. Since
nobody but the FSF seems to want real Posix.1 compliance and ANSI C
compliance in one system, I guess Reat The Standard will not be a good
clue to the behavior of Posix compliance claiming systems.
-mib
[ Personal comment here: the one vendor I personally know who had
qualms about full POSIX compliance did so because of backwards-
compatibility problems. I suspect many vendors will have the
same reservations. So, how about it: is full compliance worth
breaking old programs/scripts? --mod ]
Volume-Number: Volume 23, Number 85mib@geech.gnu.ai.mit.edu (Michael I Bushnell) (06/05/91)
Submitted-by: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
In article <1991Jun3.225808.8518@uunet.uu.net> OFM writes:
[ Personal comment here: the one vendor I personally know who had
qualms about full POSIX compliance did so because of backwards-
compatibility problems. I suspect many vendors will have the
same reservations. So, how about it: is full compliance worth
breaking old programs/scripts? --mod ]
I'm most interested in Posix.1, so I'll address that. If a compiler
switch is provided (like gcc -ansi) then full compliance is possible.
Given the _POSIX_SOURCE feature test macro, OS designers can load all
they want in, and turn it off only when _POSIX_SOURCE is defined. I'm
writing a Posix compliant system which will also be 4.4BSD compatable;
I know whereof I speak.
-mib
Volume-Number: Volume 23, Number 86sef@kithrup.COM (Sean Eric Fagan) (06/05/91)
Submitted-by: sef@kithrup.COM (Sean Eric Fagan) In article <1991Jun4.221021.26605@uunet.uu.net> mib@geech.gnu.ai.mit.edu (Michael I Bushnell) writes: >Given the _POSIX_SOURCE feature test macro, OS designers can load all >they want in, and turn it off only when _POSIX_SOURCE is defined. That doesn't do everything. Yes, it's possible to come up with a system that is not only backwards compatible, but also provides full ANSI and/or POSIX compliance (although it is not possible, necessarily, to mix old and new). Problems encountered: namespace (have to get rid of everthing not defined by ANSI for ANSI-only, everything not defined by POSIX for POSIX, and yet have to worry about old binaries, as well as sources, that may rely on such things [_iob was my favorite example, although there were several like items in libc that we had to worry a lot about]); different semantics for things of the same name (more an issue for section 1 and .2 compliance; things like df and du have portable definitions under POSIX, which may or may not be different from what old shell scripts expected). One POSIX "optional" feature, required by FIPS, was no-truncate; that is, if a filename exceeded the maximum name length for the filesystem, return ENAMETOOLONG. Do you know how many programs out there are written to generate *unique* names in 14 characters or less, but still will try to create names with *more* than 14 characters? B News, for example, I believe. Again, yes, it's possible to get around all of these. By having three seperate libraries and header files (old, ansi, and posix). By having two sets of command trees (/old and /posix; e.g., /old/bin/df and /posix/bin/df). By defining bits in the executable's header to indicate whether new features are to be used or not. (Incidently, uSoft did that, apparantly, with the OS/2 HPFS [high performance file system]: older programs which do not have the correct bit set in the header will not even *see* the longer filenames. I think this is wrong. Just MHO, though 8-).) >I'm >writing a Posix compliant system which will also be 4.4BSD compatable; >I know whereof I speak. And I helped implement a POSIX-ANSI-and-X/Open-compliant-yet-backwards- compatible system (OS, commands, and devsys) for a major vendor. I also know whereof I speak. Many people reading this group can say the same thing; most of them can probably come up with their own horror stories. 4.4 was intended to be largely POSIX compliant in the first place, and BSD places less concern on backwards compatibility than commercial vendords do (SCO, for example, can still execute, *and develop for*, XENIX/XT binaries; can a BSD system say the same about BSD 4.1?). Does this mean that SCO is "better" than CSRG? No, I didn't say that. CSRG was able to come up with a much better system, in many ways (including size, a personal peeve 8-)), and most of their "customers" have sources anyway. But the problems commercial vendors have are very *real* problems. At this point, I'm curious how SunOS did: is it still able to run binaries from 5, 10 years ago, without modification? Can it still take object modules from that long ago, and link them in with current libraries? (Some third-party people ship modules, and let the customer link them with customized pieces, for example.) -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others. Volume-Number: Volume 23, Number 87
willcox@urbana.mcd.mot.com (David A Willcox) (06/05/91)
Submitted-by: willcox@urbana.mcd.mot.com (David A Willcox) mib@geech.gnu.ai.mit.edu (Michael I Bushnell) writes: > Let us not. Let us RTFS instead. >Sigh. RTFS, of course, stands for Read The Source. Actually, at least in this context, RTFS should be taken as "Read the f-ing Standard", which in this case is unambiguous: the owner of a "mode 040" file cannot read it. What seems to be confusing people (at least the ones who actually DID read the standard) is all of the stuff about "alternative protection schemes". That's all in there to permit security enhancements like security labels (an "unclassified" process can never read ANY "secret" files) and access control lists (I'll let fred and george read the file, and harry write it when he is logged in as group "operator"). >Since >nobody but the FSF seems to want real Posix.1 compliance and ANSI C >compliance in one system, I guess Reat The Standard will not be a good >clue to the behavior of Posix compliance claiming systems. I don't think that that's true. I know of at least three vendors who are at least striving to support ANSI C and POSIX.1 on the same system. It can be done. The headers get pretty ugly, though. David A. Willcox "Just say 'NO' to universal drug testing" Motorola MCG - Urbana UUCP: ...!uiucuxc!udc!willcox 1101 E. University Ave. INET: willcox@urbana.mcd.mot.com Urbana, IL 61801 FONE: 217-384-8534 Volume-Number: Volume 23, Number 93
mib@geech.gnu.ai.mit.edu (Michael I Bushnell) (06/06/91)
Submitted-by: mib@geech.gnu.ai.mit.edu (Michael I Bushnell) In article <1991Jun5.201559.11784@uunet.uu.net> willcox@urbana.mcd.mot.com (David A Willcox) writes: >Since >nobody but the FSF seems to want real Posix.1 compliance and ANSI C >compliance in one system, I guess Reat The Standard will not be a good >clue to the behavior of Posix compliance claiming systems. I don't think that that's true. I know of at least three vendors who are at least striving to support ANSI C and POSIX.1 on the same system. It can be done. The headers get pretty ugly, though. What about name space cleanliness at link time? All the systems seem to punt on this one, and it really indicates their lack of commitment. -mib Volume-Number: Volume 23, Number 99
sef@kithrup.COM (Sean Eric Fagan) (06/12/91)
Submitted-by: sef@kithrup.COM (Sean Eric Fagan) In article <1991Jun12.034858.16429@uunet.uu.net> mib@geech.gnu.ai.mit.edu (Michael I Bushnell) writes: >What about name space cleanliness at link time? All the systems seem >to punt on this one, and it really indicates their lack of commitment. 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.) -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others. Volume-Number: Volume 23, Number 102
mib@geech.gnu.ai.mit.edu (Michael I Bushnell) (06/13/91)
Submitted-by: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
In article <1991Jun12.043706.18456@uunet.uu.net> sef@kithrup.COM (Sean Eric Fagan) writes:
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
Volume-Number: Volume 23, Number 104bitbug@public.uucp (James Buster bitbug@btr.com) (06/13/91)
Submitted-by: bitbug@public.uucp (James Buster bitbug@btr.com) In article <1991Jun12.043706.18456@uunet.uu.net> sef@kithrup.COM (Sean Eric Fagan) writes: >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.) So, for us morons out there, what are the "fairly obvious" solutions you are thinking of? -- James Buster bitbug@btr.com Seen on an MLS machine: Live Free or Die! Volume-Number: Volume 24, Number 2
sef@kithrup.COM (Sean Eric Fagan) (06/14/91)
Submitted-by: sef@kithrup.COM (Sean Eric Fagan) In article <1991Jun12.235808.20822@uunet.uu.net> mib@geech.gnu.ai.mit.edu (Michael I Bushnell) writes: >HP is *already* claiming Posix compliance, and you say one of the >solutions "will likely be used". *That* is precisely the problem. No, that is not the problem. I do not work for HP, nor have I ever in the past. As far as I know, HP solved the problem quite nicely. For the company I was working for, which was *not* HP, I and one other person spent a few weeks looking into the name-space pollution problem, how to solve it, and what it would affect in terms of compatibility with old programs and binaries. Another poster asks what the two "fairly obvious" methods are. One is to have an "ansi-only" mode, a "posix-only" mode, and a "normal" mode, probably toggled by command-line switches. Each "mode" would have its own header-file tree assosciated with it, with only the header-files defined by that standard (normal would, of course, have everything), as well as a special library and startup-file. The other way is a bit harder, but allows backwards-compatibility to work more easily (at least with supposedly-compliant programs). Essentially, you have all "illegal" symbols be "safe" (__select, for example). All library routines are written to use the __ names; then, you have the linker accept an option that tells it to try to ignore the leading __ if there are unresolved externals. You still need header-file work, of course, but that does help the name-pollution problem. If I remember correctly, both HP and AT&T did something similar. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others. Volume-Number: Volume 24, Number 3
gwyn@smoke.brl.mil (Doug Gwyn) (06/16/91)
Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn) >All library routines are written to use the __ names; then, you have the >linker accept an option that tells it to try to ignore the leading __ if >there are unresolved externals. Actually you don't need to hack the linker; you could supply a batch of glue routines in the library like this: * select -- system call interface for use by applications * (C library must invoke __select instead of select) global __select entry select select jmp __select That way both applications that supply their own select() and those that expect select() to be linked from the system library are happy. The only reasons I can think of for hacking the linker instead are (a) debugging looks neater (b) a tiny amount of time is saved by not branching (c) C library maintenance is slightly easier [ This covers functions, but not data. Such as _iob -- mod ] Volume-Number: Volume 24, Number 10
decot@hpcupt1.cup.hp.com (Dave Decot) (06/18/91)
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
peter@ficc.ferranti.com (Peter da Silva) (06/20/91)
Submitted-by: peter@ficc.ferranti.com (Peter da Silva) In article <1991Jun15.175831.6319@uunet.uu.net> sef@kithrup.COM (Sean Eric Fagan) writes: > have all "illegal" symbols be "safe" (__select, for example). All library > routines are written to use the __ names; then, you have the linker accept > an option that tells it to try to ignore the leading __ if there are > unresolved externals. You could implement this simply by having the library contain duplicate symbol table entries for __x and x, with the same offset. You could handle it in a separate pass after compilation before creating the library. No extra work should be needed in the librarian, compiler, or linker! -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?" Volume-Number: Volume 24, Number 16