🚀 go-pugleaf

>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