mailing list archives
Re: Solaris 2.5.1 party piece
From: casper () HOLLAND SUN COM (Casper Dik)
Date: Thu, 3 Jul 1997 21:00:37 +0200
It seems that Sun has finally fixed this.
Patch 103093-13 (Solaris 2.5 SPARC) claims to fix (among others) the
1238582 privileged ifconfig ioctls by normal user succeed on sockets created as
[[ What I'm saying here is in no way the official Sun view on things;
it's an explanation from my point of view inside Sun why this fix took
so long in coming; I was involved in part of the discussion as I
filed the bug. I am, however, about an ocean and a continent removed
from the place were "things happen" and as such I can't even testify to
what I write here being even close to the truth. Now that I'm writing
this I'm thinking long and hard of whether I should even mail this out
or not; if you read this, apparently I have decided for it.]]
When Alan Cox posted his message, a patch for 5.3 was already out.
The bug was already in the kernel jumbo patch queue for all other
releases under active maintenance (2.3 and up).
However, it takes a minimum of 6 to 8 weeks for a kernel patch to pass
all tests. If new bugs are introduced as a result, those are fixed in the
next release which would cause a further one month delay as bugs are
combined into new "kernel updates" about once a month.
This process was introduced for a reason; those of you who remember running
Solaris when 2.3 was the latest version probably know all too well why.
[[ Checking with "grep ^Date" in the 2.4 patch archive it seems that this
measure was not introduced until mid '95 ]]
Also, around that time it must have been decided that kernel patches
will only include the kernel unless it is absolutely necessary that the
kernel patch and another patch are applied at the same time.
This is evidenced by the fact that the 2.5* kernel patches are much
leaner than the 2.4 and before variants.
This particular bugs was specifically delayed because it first needed
to be discussed where exactly to fix the bug. Down stream where the ioctl
is performed, all that is available is the "cred*" passed down from
above. This "cred*" traditionally is the "cred*" that lives in the vnode;
the cred* of the process that opens/creates the stream. That pointer
doesn't change when the fd gets inherited, such as with rshd or rexecd.
Note that this is actually normal for files; a file opened as root but then
handed to a normal user can be manipulated by that normal user as is he
is root. E.g., his quota or read/write permissions to the file don't
In the discussion it soon became clear that there are several options to
fix this; one option being inventing an "fcntl" to change the credentials
on a STREAM/file. That would have required changing many daemons.
A second, more esthetically pleasing, option was changing the credentials
passed down to those of the calling process rather than those of the
opening process as this would require no code changes outside the kernel.
Implementing the second option was decided on but that required a
change to the semantics of *all* STREAMs ioctl() calls. (pass ioctl()
time credentials rather than open() time credentials). Since this was
considered to be a risky fix, it was first deployed in Solaris 2.6
alpha/beta. Since the original beta program was more limited than
initially intended the patching of the bug got further delayed as
further exposure in the Early Access program was deemed necessary. The
bug got put in the kernel patch queue sometime after the start of EA
Only know the patches are coming of the other end.
Such is the history of bug #1238582.
Alan Cox' message to bugtraq has not expedited the patch process in any