[comp.unix.questions] System V letting random users chown

pdb@sei.cmu.edu.UUCP (03/15/87)

Hmm...looks like my ignorance of the "offical" AT&T Unixes is showing.
But then again, I use real Unix, not System V :-).

Anyway, if System V clears the 6000 bits of the file protection, then
the set-uid glitch is a non-issue, but opens up a bunch of other problems.
I, for one, wouldn't want there to be any way for a non-root user to make
it look like I created some random file (like, for instance, writing a program
to do some anti-social thing like a mkdir/chdir loop, moving it into /usr/tmp,
and chowning it to me).  Is there any way to track the original creator of
a file?

For files that need to be accessed by groups of people, the BSD group list
concept really works much better (does Sys V have an analog to this?)

And speaking of "official" AT&T Unix, does anyone know if they ever plan
to make Eighth Edition Unix available outside of AT&T?

--Pat.

guy%gorodish@Sun.COM (Guy Harris) (03/16/87)

>Is there any way to track the original creator of a file?

No.

>For files that need to be accessed by groups of people, the BSD group list
>concept really works much better (does Sys V have an analog to this?)

No.

>And speaking of "official" AT&T Unix, does anyone know if they ever plan
>to make Eighth Edition Unix available outside of AT&T?

Eighth Edition is dead; long live Ninth Edition.  I think a few
universities have V8; I don't know whether they're getting V9 or not.

ecl@mtgzy.UUCP (03/16/87)

In article <15054@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes:
> >For files that need to be accessed by groups of people, the BSD group list
> >concept really works much better (does Sys V have an analog to this?)
> 
> No.

Pardon my ignorance of BSD, but what's wrong with the use of group permissions
and /etc/group in Sys V for group access?  We've used it (on several projects)
for years and it's worked quite well.

					Evelyn C. Leeper
					(201) 957-2070
				UUCP:	ihnp4!mtgzy!ecl
				ARPA:	mtgzy!ecl@rutgers.rutgers.edu

ram@nucsrl.UUCP (Raman Renu) (03/17/87)

Sorry, I could not resist this silly crack:
guy%gorodish@Sun.COM (Guy Harris) wrote:

>>And speaking of "official" AT&T Unix, does anyone know if they ever plan
>>to make Eighth Edition Unix available outside of AT&T?

>Eighth Edition is dead; long live Ninth Edition.  I think a few
>universities have V8; I don't know whether they're getting V9 or not.
		   ^^
		   ++---  And all Grocery Stores.  That's called software
"off-the-shelf".   
>----------

					      renu raman
					      ...ihnp4!nucsrl!ram

guy%gorodish@Sun.COM (Guy Harris) (03/17/87)

> Pardon my ignorance of BSD, but what's wrong with the use of group
> permissions and /etc/group in Sys V for group access?  We've used it (on
> several projects) for years and it's worked quite well.

You can use groups in the same way on systems with the 4BSD group
mechanism (this includes IBM's AIX, almost) that you do on systems
without it.  However, if you frequently switch between groups - or
have to work with two different files that are in two different
groups and are NOT readable/writable by the world - the 4BSD group
mechanism is a win.

How it works:

	In addition to the effective and real user and group IDs for
	a process, there is also a "group set" for the process.  If
	the effective user ID of a process does not match the user ID
	owning a file, but either the effective group ID *or* any
	member of the group set of a process matches the group ID
	owning the file, then the group permission bits are used to
	grant access to the file.

	In addition, when a file is created, the group ID that owns
	the file is not set from the effective group ID of the
	process, but is set from the group ID that owns the directory
	in which the file is being created.  (This is why I said
	"almost" above; AIX doesn't do this.)

	When you log in, your effective group ID is set to the number
	in the group field of your "/etc/passwd" entry.  Your group
	set is initialized from { group ID in "/etc/passwd" } (union)
	<set of groups in "/etc/group" that you belong to> (although
	if this exceeds 16, only the first 16 groups are used).

There is no "newgrp" command in 4.[23]BSD; it's not needed.

(And next week, we talk about files with component names longer than
14 characters, "CRT erase" modes that can erase tabs, etc. properly,
and other nice things....)