tan@bronson.uucp (Tan Bronson) (04/06/91)
The 2.2.1 concept of groups seems to be either broken or different
than BSDs. On BSD uses multiple groups for file permission/access checking,
but on 2.2.1 being a member of groups other than one's login group
does not allow one to get access to files in those other groups!
Is this a bug or are these groups only for NFS purposes?
Do groups work in V.4 the same as BSD?
Is there a fix for this? (I thought SSU1.a fixed this problem, but nooooo)
--
Tan Bronson tan@Microvation.COM (or tan@bronson.UUCP)
Microvation Consultants 20 Sperry Road Madison, CT 06443
Voice: (203)-421-5061 Fax: (203)-421-5292gemini@geminix.in-berlin.de (Uwe Doering) (04/06/91)
tan@bronson.uucp (Tan Bronson) writes: > The 2.2.1 concept of groups seems to be either broken or different >than BSDs. On BSD uses multiple groups for file permission/access checking, >but on 2.2.1 being a member of groups other than one's login group >does not allow one to get access to files in those other groups! This only works if you switch the whole kernel in POSIX mode. This is done with the help of a special start-up file (*crtp*.o) that is linked with your program instead of the standard start-up file. In this POSIX start-up file there is a call to the POSIX function __setostype(). This sets the `u_ostype' variable in the user structure (look at /usr/include/sys/user.h) to `1', and from thereon the kernel works in POSIX mode (only for this process !) until the process dies. Unfortunately, running programs that are compiled for the SysVr3 environment in POSIX mode won't work in many cases because there are plenty of incompatibilities between SysVr3 and POSIX. That is, even compiling these programs with the POSIX start-up file and POSIX library won't help because most software relies on a certain behavior of your operating system if you tell it that you have a SysVr3 UNIX version. For instance, giving away file ownerships to other users is allowed for every user under SysVr3. Under POSIX, only root can do that. And there are lots of other problems like this. Therefore, many applications will break. After realizing this I concluded that the only way to enable the group vector feature independently from the POSIX switch in the user area was to patch the responsible kernel module. And this is exactly what I did. Go to the directory /etc/conf/pack.d/s5 and apply the following patch to `Driver.o' (after making a backup of this file): This is for ISC 2.2.1 with the security fix installed (SSU.15). The original code looks like this: ------------------------- cut here --------------------------- 2b1f: 3b c2 cmpl %edx,%eax [%edx,%eax] 2b21: 0f 84 ff 00 00 00 je 0xff <2c26> [0x2c26] 2b27: 0f be 05 6c 14 00 00 movsbl 0x146c,%eax [0x146c,%eax] 2b2e: 3d 01 00 00 00 cmpl $0x1,%eax [$0x1,%eax] 2b33: 0f 85 e6 00 00 00 jne 0xe6 <2c1f> [0x2c1f] 2b39: a1 70 14 00 00 movl 0x1470,%eax [0x3fae,%eax] 2b3e: 89 45 f8 movl %eax,0xf8(%ebp) [%eax,-8+%ebp] 2b41: c7 45 fc 00 00 00 00 movl $0x0,0xfc(%ebp) [$0x0,-4+%ebp] 2b48: e9 9c 00 00 00 jmp 0x9c <2be9> [0x2be9] 2b4d: 90 nop [] 2b4e: 90 nop [] 2b4f: 90 nop [] ------------------------- cut here --------------------------- and ------------------------- cut here --------------------------- 4a08: 3b c2 cmpl %edx,%eax [%edx,%eax] 4a0a: 0f 84 b6 00 00 00 je 0xb6 <4ac6> [0x4ac6] 4a10: 0f be 05 6c 14 00 00 movsbl 0x146c,%eax [0x146c,%eax] 4a17: 3d 01 00 00 00 cmpl $0x1,%eax [$0x1,%eax] 4a1c: 0f 85 a1 00 00 00 jne 0xa1 <4ac3> [0x4ac3] 4a22: a1 70 14 00 00 movl 0x1470,%eax [0x5e97,%eax] 4a27: 89 45 f8 movl %eax,0xf8(%ebp) [%eax,-8+%ebp] 4a2a: c7 45 fc 00 00 00 00 movl $0x0,0xfc(%ebp) [$0x0,-4+%ebp] 4a31: eb 5a jmp 0x5a <4a8d> [0x4a8d] 4a33: 90 nop [] ------------------------- cut here --------------------------- After the patch it looks like this: ------------------------- cut here --------------------------- 2b1f: 3b c2 cmpl %edx,%eax [%edx,%eax] 2b21: 0f 84 ff 00 00 00 je 0xff <2c26> [0x2c26] 2b27: 0f be 05 6c 14 00 00 movsbl 0x146c,%eax [0x146c,%eax] 2b2e: 3d 01 00 00 00 cmpl $0x1,%eax [$0x1,%eax] 2b33: 90 nop [] 2b34: 90 nop [] 2b35: 90 nop [] 2b36: 90 nop [] 2b37: 90 nop [] 2b38: 90 nop [] 2b39: a1 70 14 00 00 movl 0x1470,%eax [0x3fae,%eax] 2b3e: 89 45 f8 movl %eax,0xf8(%ebp) [%eax,-8+%ebp] 2b41: c7 45 fc 00 00 00 00 movl $0x0,0xfc(%ebp) [$0x0,-4+%ebp] 2b48: e9 9c 00 00 00 jmp 0x9c <2be9> [0x2be9] 2b4d: 90 nop [] 2b4e: 90 nop [] 2b4f: 90 nop [] ------------------------- cut here --------------------------- and ------------------------- cut here --------------------------- 4a08: 3b c2 cmpl %edx,%eax [%edx,%eax] 4a0a: 0f 84 b6 00 00 00 je 0xb6 <4ac6> [0x4ac6] 4a10: 0f be 05 6c 14 00 00 movsbl 0x146c,%eax [0x146c,%eax] 4a17: 3d 01 00 00 00 cmpl $0x1,%eax [$0x1,%eax] 4a1c: 90 nop [] 4a1d: 90 nop [] 4a1e: 90 nop [] 4a1f: 90 nop [] 4a20: 90 nop [] 4a21: 90 nop [] 4a22: a1 70 14 00 00 movl 0x1470,%eax [0x5e97,%eax] 4a27: 89 45 f8 movl %eax,0xf8(%ebp) [%eax,-8+%ebp] 4a2a: c7 45 fc 00 00 00 00 movl $0x0,0xfc(%ebp) [$0x0,-4+%ebp] 4a31: eb 5a jmp 0x5a <4a8d> [0x4a8d] 4a33: 90 nop [] ------------------------- cut here --------------------------- In words: I simply eliminated two conditional jumps so that the code for the group vector checking is always executed. You should be able to apply this patch with any binary file editor. Of course, I give you _no_ guaranty that this patch will work you nor that it won't crash your system. However, for me this works like a charm. Of course, the group vector must be set before you can use it. This is done by the `login' program. I haven't checked whether the original ISC `login' has the necessary initgroups() function call in it (from `libcposix.a') because I use a PD login program. If `login' sets the group vector, all of its child processes (including the execed login shell) will use it. Nice feature. It's really sad that ISC didn't make this really useful feature configurable independently from the POSIX switch, for instance by a variable in /etc/conf/pack.d/s5/space.c. :-( Have fun! Uwe -- Uwe Doering | INET : gemini@geminix.in-berlin.de Berlin |---------------------------------------------------------------- Germany | UUCP : ...!unido!fub!geminix.in-berlin.de!gemini
cpcahil@virtech.uucp (Conor P. Cahill) (04/07/91)
tan@bronson.uucp (Tan Bronson) writes: > The 2.2.1 concept of groups seems to be either broken or different >than BSDs. On BSD uses multiple groups for file permission/access checking, >but on 2.2.1 being a member of groups other than one's login group >does not allow one to get access to files in those other groups! ISC groups are POSIX groups which are the same as BSD groups. However, to use ISC groups, each program must be compiled to use the POSIX universe. I don't know why ISC didn't just make that the standard behavior. For normal users/programs you need to run newgrp, which is like su in that it spawns a new shell with the new group id, but the old shell is gone and you would need to do another newgrp to go back. > Do groups work in V.4 the same as BSD? Yes. > Is there a fix for this? (I thought SSU1.a fixed this problem, but nooooo) Nope. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
sef@kithrup.COM (Sean Eric Fagan) (04/07/91)
In article <6UQPL0V@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes: >In this >POSIX start-up file there is a call to the POSIX function __setostype(). This is not a function specified by POSIX. >For instance, giving away file ownerships to other users is allowed >for every user under SysVr3. Under POSIX, only root can do that. Not true. POSIX allows either (standard SysV or BSD-style) behaviour. FIPS took the "option," thus requiring, for certain government bids, the OS to restrict chgrp's (and chown's). SCO allows this to be set on a per-individual basis, incidently; one of the few things I like about the SecureWare stuff. -- 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.
gemini@geminix.in-berlin.de (Uwe Doering) (04/07/91)
sef@kithrup.COM (Sean Eric Fagan) writes: >In article <6UQPL0V@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes: >>In this >>POSIX start-up file there is a call to the POSIX function __setostype(). > >This is not a function specified by POSIX. > >>For instance, giving away file ownerships to other users is allowed >>for every user under SysVr3. Under POSIX, only root can do that. > >Not true. POSIX allows either (standard SysV or BSD-style) behaviour. FIPS >took the "option," thus requiring, for certain government bids, the OS to >restrict chgrp's (and chown's). SCO allows this to be set on a >per-individual basis, incidently; one of the few things I like about the >SecureWare stuff. Well, I may be wrong about what feature is POSIX, and what is not (as my description is only based on what ISC has implemented), but this doesn't prevent the patch from working. :-) Uwe -- Uwe Doering | INET : gemini@geminix.in-berlin.de Berlin |---------------------------------------------------------------- Germany | UUCP : ...!unido!fub!geminix.in-berlin.de!gemini
eric@mks.mks.com (Eric Gisin) (04/08/91)
If anyone is considering making this patch, you should note that only /bin/login does an initgroups() to set up the group list from /etc/group. /etc/netlogin and /etc/rshd do *not* set up the group list. Netlogin affects all telnet and rlogin logins, and rshd affects any xterms started remotely. I reported the problem with netlogin to ISC, and also told them I would like to see the group list used for System V mode as well as POSIX mode.
grant@bluemoon.uucp (Grant DeLorean) (04/09/91)
tan@bronson.uucp (Tan Bronson) writes: > The 2.2.1 concept of groups seems to be either broken or different >than BSDs. On BSD uses multiple groups for file permission/access checking, >but on 2.2.1 being a member of groups other than one's login group >does not allow one to get access to files in those other groups! Look up the man page for newgrp and it will explain a lot for you... -- \ Grant DeLorean (grant@bluemoon) {n8emr|nstar}!bluemoon!grant / "You need only reflect that one of the best ways to get yourself a reputation as a dangerous citizen these days is to go about repeating the very phrases which our founding fathers used in the struggle for independence."-C.A. Beard
greg@cheers.Bungi.COM (Greg Onufer) (04/10/91)
grant@bluemoon.uucp (Grant DeLorean) writes: > Look up the man page for newgrp and it will explain a lot for you... That's not what Tan (the poster to whom you are replying) wants to know. newgrp doesn't figure into how BSD handles multiple groups (and how Tan obviously wants them to work). newgrp is the inconvenient S5'ism to allow access to multiple groups. Cheers!greg