idavis@mach2.WLU.CA (Ian Davis) (06/13/91)
It was my belief that if a C program created new files these files would automatically be assigned the effective user and group id of the executing program. Ie. If the set gid bit is set on the executable code, then files created by this code would belong to the same group as that associated with this code. This appears to be the case on AT&T UNIX. However under ''DYNIX(R) V3.0.17.9 Sun Jan 7 03:03:31 PST 1990'' I find that such output files appear to be assigned the real user id of the invoking user instead. Am I correct, and would others consider this a bug, or a feature? Given this behaviour, how can a program change the attributes of a file that it has created to reflect this programs effective rather than real group id. Using chown(file_name,-1,getegid()) merely results in an error return code, since the invoker does not have superuser permissions. I do not wish to change the effective user id of the software which creates these database to root, because of the security implications. Apart from anything else a malicious user could create hundreds of database files anywhere they wanted. My reason for wanting to change the group id of created files is so that authorised database software has unrestricted access to databases which are created, since they run under this same effective group id, but end users have no direct ability to read, update or delete these databases, unless they are identified as owning them. Thanks for any reply.. Dr. Ian Davis Net Address: idavis@mach2.WLU.CA Computing Services Local Mail: P4-2, Main Campus Wilfrid Laurier University, Waterloo, Ontario Telephone: (519)884-1970 x2764 -- Dr. Ian Davis Net Address: idavis@mach2.WLU.CA Computing Services Local Mail: P4-2, Main Campus Wilfrid Laurier University, Waterloo, Ontario Telephone: (519)884-1970 x2764
@sequent.com (Robin O'Neill) (06/13/91)
>From: idavis@mach2.WLU.CA (Ian Davis) >It was my belief that if a C program created new files these files would >automatically be assigned the effective user and group id of the executing >program. Ie. If the set gid bit is set on the executable code, then files >created by this code would belong to the same group as that associated with >this code. This appears to be the case on AT&T UNIX. However under >''DYNIX(R) V3.0.17.9 Sun Jan 7 03:03:31 PST 1990'' I find that such output >files appear to be assigned the real user id of the invoking user instead. >Am I correct, and would others consider this a bug, or a feature? You are not the first in the industry to be confused by this issue :-). Traditional BSD UNIX implementations assign the effective user id of the creating process and the group id of the parent directory as the uid and gid (respectively) of newly created files. This is the behavior that DYNIX V3.0.17 demonstrates. I.e., the gid of the newly created file is inherited from the file's parent directory, not from the effective/real gid of the creating process. It is likely that the gid of the parent directory of the file your creating is equal (just by coincidence) to the real gid of the creating process. You are correct regarding the differing behavior of most AT&T UNIX implementations. They assign the effective uid and gid of the creating process as the uid and gid (respectively) of newly created files (the gid of the parent directory is ignored). Note that POSIX-FIPS conforming UNIX implementations (e.g., DYNIX/ptx) adhere to the BSD-style of uid/gid assignments of newly created files. > >Given this behaviour, how can a program change the attributes of a file that >it has created to reflect this programs effective rather than real group id. >Using chown(file_name,-1,getegid()) merely results in an error return code, >since the invoker does not have superuser permissions. I do not wish to >change the effective user id of the software which creates these database >to root, because of the security implications. Apart from anything else >a malicious user could create hundreds of database files anywhere they >wanted. > >My reason for wanting to change the group id of created files is so that >authorised database software has unrestricted access to databases which are >created, since they run under this same effective group id, but end users >have no direct ability to read, update or delete these databases, unless >they are identified as owning them. To avoid creating any setuid root processes, you could change the gid of the directory (or directories) where the database files will be created to match the desired gid of the resulting files. Of course, this assumes that these files will always be created in a "known" directory (or set of directories). Or, you're program could fork()/exec() (or use the system() library routine) the /bin/chgrp executable to perform the "chown(file_name, -1, getegid())" on behalf of the creating process. /bin/chgrp is a setuid root command which validates that the invoking process is either the owner of the file or belongs to the specified group and then changes the group accordingly. I hope this helps. -rto- > >Thanks for any reply.. > >Dr. Ian Davis Net Address: idavis@mach2.WLU.CA >Computing Services Local Mail: P4-2, Main Campus >Wilfrid Laurier University, Waterloo, Ontario Telephone: (519)884-1970 x2764 > ------------------------------------------------------------------------------- Robin T. O'Neill uucp: uunet!sequent!rto Sequent Computer Systems, Inc. internet: rto@sequent.com Mail Stop DES2-741 telephone: (503) 578-4277 15450 S.W. Koll Parkway wireless: N7QPG (2m FM 147.04MHz) Beaverton, Oregon 97006-6063 in-person: Hey You