larry@morpho.UUCP (Larry Morris) (09/06/90)
I am having some problems getting our RCS package running on the 6000. The co commmand runs as suid rcs. After checking out the file it then attempts to chown() the file to the correct owner. This works fine on AIX2 and on the systems we originally ported from, but not on AIX 3. The chown() call now requires that co have root permissions in order to perform the chown. In my case, although co "owns" the file the chown() returns EPERM (obvious, but not listed in the man pages). As usual IBM says tough, it works as documented. Who cares if it acts like unix? I can see where this might fix some serious security holes inherent with remote file systems, but does the rest of the world do this? Or is this another one of IBM's better ideas? I am open to suggestions on how to work around this, although I'm not very open to having the entire RCS package run suid root. Maybe I'll just write a small program to do all my chowns and have it run suid root. :-)/2
marc@marc.watson.ibm.com (Marc Auslander) (09/06/90)
In article <384@morpho.UUCP>, larry@morpho.UUCP (Larry Morris) writes: |> The chown() call now requires that co have root permissions in order to |> perform the chown. In my case, although co "owns" the file the chown() |> returns EPERM (obvious, but not listed in the man pages). As usual IBM |> says tough, it works as documented. Who cares if it acts like unix? |> What is "unix". In fact, the chown change was a move from the system V semantics to BSD semantics. chown on V3 works as it does on (at least) BSD and SUN. The reason is that in a controlled shared user system it is real trouble if one user can "give" files to another. The user who is "given" the file will not be able to find it, let alone rm it, but he'll pay for the space! Yes, I'd write an SUID program (with appropriate checks) to do this application.
drake@drake.almaden.ibm.com (09/07/90)
In article <384@morpho.UUCP> larry@morpho.UUCP (Larry Morris) writes: >The chown() call now requires that co have root permissions in order to >perform the chown. > >I can see where this might fix some serious security holes inherent with >remote file systems, but does the rest of the world do this? Or is this >another one of IBM's better ideas? The POSIX 1003.1 spec allows (but does not mandate) this behavior. The commentary portion of the spec discusses this issue: System III and System V allow a user to give away files .... This is a serious problem for implementations which are intended to meet government security regulations. Version 7 and 4.3BSD permit only the super-user to change the user ID of a file. ... The standard uses (the word) "may" to permit secure implementations while not disallowing System V. So this isn't an IBM invention, by any means; it's part of IBM's intent to conform to POSIX and to emulate BSD as closely as possible. Sam Drake / IBM Almaden Research Center Internet: drake@ibm.com BITNET: DRAKE at ALMADEN Usenet: ...!uunet!ibmarc!drake Phone: (408) 927-1861
jeffe@sandino.austin.ibm.com (Peter Jeffe 512.823.4091) (09/07/90)
In article <384@morpho.UUCP> larry@morpho.UUCP (Larry Morris) writes: >The chown() call now requires that co have root permissions in order to >perform the chown. In my case, although co "owns" the file the chown() >returns EPERM (obvious, but not listed in the man pages). As usual IBM >says tough, it works as documented. Who cares if it acts like unix? > >I can see where this might fix some serious security holes inherent with >remote file systems, but does the rest of the world do this? Or is this >another one of IBM's better ideas? Well, BSD systems work this way, but I believe SysV doesn't. The idea is that it prevents users from evading quotas by "giving away" their files. And yes, IBM changed the behavior of chown() in AIX3 to make it act like *BSD* (and POSIX) Unix. Believe me, it caused problems for us as well, but we'll both have to live with it, as applications on BSDish systems do. ------------------------------------------------------------------------------- Peter Jeffe ...uunet!cs.utexas.edu!ibmaus!auschs!sandino.austin.ibm.com!jeffe first they want a disclaimer, then they make you pee in a jar, then they come for you in the night
guy@auspex.auspex.com (Guy Harris) (09/07/90)
>I can see where this might fix some serious security holes inherent with >remote file systems, but does the rest of the world do this? A lot of the rest of the world *does* do this. The original Research versions of UNIX worked that way; as one of the V6 or V7 man pages said, this was done to prevent attempts to defeat the "(non-existent) disk space accounting procedures". BSD preserved this behavior, and SunOS (definitely) and Ultrix (probably), to name a couple of systems, preserved it as well. PWB/UNIX 1.0, as I remember, made "chown" not quite so privileged, allowing a process to "give away" files that belonged to its effective UID. This propagated into S3 and S5. I seem to remember hearing that AIX 3.1 supports disk quotas (BSD-style ones, it seems); they may have made "chown" require root privilege in order to prevent attempts to defeat the (no longer non-existent) disk space accounting procedures. If so, it's in the same boat as, for example, System V Release 4, which has a configuration option to make "chown" require root privileges, so that you can't defeat the quotas that the BSD file system in S5R4 supports. >Or is this another one of IBM's better ideas? I am open to suggestions on >how to work around this, although I'm not very open to having the entire >RCS package run suid root. I assume you have some reason why "co" needs to run set-UID at all. As such, what you *might* want to do (if you have source to RCS) is change it so that it temporarily gives up its set-UID privileges when it creates files that should be owned by the user running "co", and then reclaims them when necessary (I assume AIX has the "saved set-user ID" notion; I would be surprised if it didn't).