[3595] in bugtraq
Re: HP-UX setprivgrp()
daemon@ATHENA.MIT.EDU (dsiebert@icaen.uiowa.edu)
Fri Nov 8 22:15:03 1996
Date: Fri, 8 Nov 1996 20:31:01 -0600
Reply-To: dsiebert@icaen.uiowa.edu
From: dsiebert@icaen.uiowa.edu
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>
In-Reply-To: <199611082002.PAA19494@black-ice.cc.vt.edu> from
"Valdis.Kletnieks@vt.edu" at Nov 8, 96 03:02:07 pm
> On Thu, 07 Nov 1996 22:51:54 +0100, Valdis Kletnieks (Valdis.Kletnieks@vt.edu) wrote:
> >
> > Don't bother trying, system calls are atomic... but you can use this
>
> Have you in fact verified that this is guaranteed true on a multiprocessor
> system? Remember that the other side(s) of the machine can still be
> running, and the kernel needs to explicitly lock out any activity that
> it doesn't want to be seen.
>
> Doing this in an efficient manner is in fact the single hardest thing with
> building a good MP system - you have to minimize the locked sections of code
> so the other CPUs can proceed as often as possible. I haven't checked a
> Unix kernel, but IBM's VM operating system has on the order of 200 or so
> different locks to provide as fine granularity as needed. Of course,
> sometimes the lock turns out to be a bit TOO granular.. ;)
The kernel locking doesn't matter here, the inode itself is locked by the OS
while being modified, so another CPU would wait for the first to be done, even
if the kernel was fully was threaded so the chown and chmod calls were able
to run in parallel. I know its this way in HP-UX, I suspect it is this way in
all Unixes.
If you don't want your HP-UX system to allow users to give away files (which
is the standard SysV behavior) create a file called /etc/privgroup with "-g"
in it, and this will be used as an argument to a setprivgrp call on startup
which will prevent this.
--
Douglas Siebert Director of Computing Facilities
douglas-siebert@uiowa.edu Division of Mathematical Sciences, U of Iowa
Ack! My reality check just bounced!!
