haynes@ucbarpa.Berkeley.EDU.UUCP (03/12/87)
I had a maddening problem in which a member of a group could not execute a program that was setgid to that group. After some fuddling around I chmoded the program again and suddenly it worked. Turned out that a mistake in a makefile had caused the program to be installed originally with mode 2701 - not executable by the group - but of course ls -l shows rwx--s--x as if all were well. Jim Haynes ...ucbvax!ucscc!haynes haynes@ucbarpa.berkeley.edu haynes@ucscc.bitnet
jgy@hropus.UUCP (03/12/87)
> I had a maddening problem in which a member of a group could not > execute a program that was setgid to that group. After some fuddling > around I chmoded the program again and suddenly it worked. Turned > out that a mistake in a makefile had caused the program to be > installed originally with mode 2701 - not executable by the group - > but of course ls -l shows rwx--s--x as if all were well. > > Jim Haynes > ...ucbvax!ucscc!haynes > haynes@ucbarpa.berkeley.edu > haynes@ucscc.bitnet > On SVR2 systems if a 's' is NOT covering an 'x' it is shown in upper-case so ls would have shown rwx--S--x
kdw1@sphinx.UUCP (03/12/87)
In <17803@ucbvax.BERKELEY.EDU> haynes@ucbarpa.Berkeley.EDU (Jim Haynes)
writes:
I had a maddening problem in which a member of a group could not
execute a program that was setgid to that group. After some fuddling
around I chmoded the program again and suddenly it worked. Turned
out that a mistake in a makefile had caused the program to be
installed originally with mode 2701 - not executable by the group -
but of course ls -l shows rwx--s--x as if all were well.
I don't know what version of Unix you're using (4.[23]?), but System V
(release 2.0 and higher)'s ls would have displayed a capital S in the
example above to indicate that the execute permission was not set. I quote
from the man page:
The indications of set-ID and 1000 bits of the mode are capitalized
(S and T respectively) if the corresponding execute permission is
*not* set.
(I.e., same trick for the sticky bit.)
This saved me from your experience once. I set-uid a file, did an
ls -l to check, and that capital S jumped out at me. All I knew was
I had never seen *that* before, so I checked the manual and discovered
my mistake.
Keith
--
Keith Waclena BITNET: xrtkdw1@uchimvs1.bitnet
University of Chicago UUCP: ...ihnp4!gargoyle!sphinx!kdw1
Graduate Library School Internet: keith@gargoyle.uchicago.eduguy@gorodish.UUCP (03/12/87)
>Turned out that a mistake in a makefile had caused the program to be >installed originally with mode 2701 - not executable by the group - >but of course ls -l shows rwx--s--x as if all were well. The S5 version of "ls" shows a sticky, set-UID, or set-GID bit that lacks the matching execute bit as a capital letter; we dropped that into the 4.2 environment "ls" here as well.
matt@oddjob.UUCP (03/12/87)
In article <1264@sphinx.UChicago.UUCP> kdw1@sphinx.UUCP (Keith Waclena) writes: ) I don't know what version of Unix you're using (4.[23]?), but System V ) (release 2.0 and higher)'s ls would have displayed a capital S in the ) example above to indicate that the execute permission was not set. Good idea. Here's a change to the 4.3 "ls" (and its man page) to do the same thing. *** /tmp/,RCSt1016260 Thu Mar 12 14:28:21 1987 --- ls.c Thu Mar 12 14:24:36 1987 *************** *** 575,587 **** int m1[] = { 1, S_IREAD>>0, 'r', '-' }; int m2[] = { 1, S_IWRITE>>0, 'w', '-' }; ! int m3[] = { 2, S_ISUID, 's', S_IEXEC>>0, 'x', '-' }; int m4[] = { 1, S_IREAD>>3, 'r', '-' }; int m5[] = { 1, S_IWRITE>>3, 'w', '-' }; ! int m6[] = { 2, S_ISGID, 's', S_IEXEC>>3, 'x', '-' }; int m7[] = { 1, S_IREAD>>6, 'r', '-' }; int m8[] = { 1, S_IWRITE>>6, 'w', '-' }; ! int m9[] = { 2, S_ISVTX, 't', S_IEXEC>>6, 'x', '-' }; int *m[] = { m1, m2, m3, m4, m5, m6, m7, m8, m9}; --- 575,587 ---- int m1[] = { 1, S_IREAD>>0, 'r', '-' }; int m2[] = { 1, S_IWRITE>>0, 'w', '-' }; ! int m3[] = { 3, S_ISUID|(S_IEXEC>>0), 's', S_ISUID, 'S', S_IEXEC>>0, 'x', '-' }; int m4[] = { 1, S_IREAD>>3, 'r', '-' }; int m5[] = { 1, S_IWRITE>>3, 'w', '-' }; ! int m6[] = { 3, S_ISGID|(S_IEXEC>>3), 's', S_ISGID, 'S', S_IEXEC>>3, 'x', '-' }; int m7[] = { 1, S_IREAD>>6, 'r', '-' }; int m8[] = { 1, S_IWRITE>>6, 'w', '-' }; ! int m9[] = { 3, S_ISVTX|(S_IEXEC>>6), 't', S_ISVTX, 'T', S_IEXEC>>6, 'x', '-' }; int *m[] = { m1, m2, m3, m4, m5, m6, m7, m8, m9}; *************** *** 596,604 **** register int *pairp = *mp++; register int n = *pairp++; ! while (--n >= 0 && (flags&*pairp++) == 0) ! pairp++; ! *lp++ = *pairp; } return (lp); } --- 596,604 ---- register int *pairp = *mp++; register int n = *pairp++; ! while (--n >= 0 && (flags&*pairp) != *pairp) ! pairp += 2; ! *lp++ = pairp[n>=0]; } return (lp); } *** man/man1/ls.1 Mon May 12 16:32:00 1986 --- man.local/man1/ls.1 Thu Mar 12 14:37:56 1987 *************** *** 3,8 **** --- 3,9 ---- .\" specifies the terms and conditions for redistribution. .\" .\" @(#)ls.1 6.4 (Berkeley) 5/12/86 + .\" reflect printing of 'S' or 'T' when unset 'x' bit is hidden .\" .TH LS 1 "May 12, 1986" .UC *************** *** 195,200 **** --- 196,206 ---- See .IR chmod (1) for the meaning of this mode. + Usually the `s' and `t' characters hide an execute permission bit + which is set. + If the hidden bit is + .I not + set, then `S' or `T' is printed instead. .PP When the sizes of the files in a directory are listed, a total count of blocks, ________________________________________________________ Matt University matt@oddjob.uchicago.edu Crawford of Chicago {astrovax,ihnp4}!oddjob!matt
rjnoe@uniq.UUCP (03/13/87)
In article <1264@sphinx.UChicago.UUCP>, kdw1@sphinx.UChicago.UUCP (Keith Waclena) writes: > > In <17803@ucbvax.BERKELEY.EDU> haynes@ucbarpa.Berkeley.EDU (Jim Haynes) > writes: >> installed originally with mode 2701 - not executable by the group - >> but of course ls -l shows rwx--s--x as if all were well. > > I don't know what version of Unix you're using (4.[23]?), but System V > (release 2.0 and higher)'s ls would have displayed a capital S in the > example above to indicate that the execute permission was not set. That is true of Bell Labs UNIX at least as far back as System III, maybe further, and up through System V Release 2 (any version). But in System V Release 3 that 02701 mode would show up as "rwx--l--x", i.e. 'l' (the lowercase letter) in place of 'S'. Also, the chmod(1) command has added options +l and -l (although the ugo prefixes in this case are meaningless). This is to permit mandatory locking on the file. That is, the semantics of what used to be "set group id but group may not execute" has changed to "cause locks to be mandatory rather than advisory". If you then try to do any chmod on the file that would attempt to set the group-execute permission (chmod g+x or any superset thereof) you would get the warning that it's a lockable file and (group) execute permission cannot be set. Beginning in SVR3 it's impossible to have a file that's set-group-id yet not executable by the group. -- "Uniqs System V Release 3 - coming soon to a VAX near you!" Roger Noe ihnp4!uniq!rjnoe Uniq Digital Technologies rjnoe@uniq.UUCP 28 South Water Street +1 312 879 1566 Batavia, Illinois 60510 41:50:56 N. 88:18:35 W.
ivanlan%mycroft@gswd-vms.arpa (03/13/87)
>From: Jim Haynes <haynes@ucbarpa.Berkeley.EDU> >Subject: ls -l obscures important information >Date: 12 Mar 87 06:31:54 GMT >Sender: usenet@ucbvax.BERKELEY.EDU >I had a maddening problem in which a member of a group could not >execute a program that was setgid to that group. After some fuddling >around I chmoded the program again and suddenly it worked. Turned >out that a mistake in a makefile had caused the program to be >installed originally with mode 2701 - not executable by the group - >but of course ls -l shows rwx--s--x as if all were well. >Jim Haynes > ...ucbvax!ucscc!haynes system V ls does this better; it uses 'S' instead of 's' if the execute bit is not also set: -rwx--S--x 1 ivanlan staff 6 Mar 13 11:43 xxx sysV ls is broken plenty of other ways, though. but then, so is bsd ls. i fixed my ls, by the way, so it works properly: - 2701 1 ivanlan staff 6 Mar 13 11:43 xxx ------------------ ivan van laningham gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!ivanlan arpa: ivanlan@gswd-vms disclaimer: "ls -ivanlan considered dangerous"
pdg@ihdev.UUCP (03/14/87)
In article <909@hropus.UUCP> jgy@hropus.UUCP (John Young) writes: >On SVR2 systems if a 's' is NOT covering an 'x' it is shown in upper-case >so ls would have shown rwx--S--x Unfortunately, the commonly used lf (available through exptools for AT&T, and through the toolchest) does not. So much for compatable software. -- Paul Guthrie ihnp4!ihdev!pdg This Brain left intentionally blank.
decot@hpisod2.UUCP (03/18/87)
> I had a maddening problem in which a member of a group could not > execute a program that was setgid to that group. After some fuddling > around I chmoded the program again and suddenly it worked. Turned > out that a mistake in a makefile had caused the program to be > installed originally with mode 2701 - not executable by the group - > but of course ls -l shows rwx--s--x as if all were well. > > Jim Haynes > ...ucbvax!ucscc!haynes On System V Interface Definition conforming systems, ls -l shows files with a 2701 mode as follows: -rwx--S--x 1 decot hp 0 Mar 18 12:35 foo However, the SVID prognosticates in FUTURE DIRECTIONS that The group execute permission bit will be shown as l if mandatory locking is enabled for the file. It will not be possible to set-group-ID without also turning on group execute permission; therefore the group execute permission character will have one of the following values: -, x, s, or l; (S will not be possible). This means that 2701 file mode would not indicate a setgid file at all, just that file locking would be enforced. Dave Decot Hewlett-Packard Company hpda!decot