Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 30 Aug 2003 10:57:07 -0400 (EDT)
From:      Robert Watson <rwatson@freebsd.org>
To:        Kenneth Culver <culverk@yumyumyum.org>
Cc:        freebsd-ports@freebsd.org
Subject:   Re: 2 ports broken after gcc import
Message-ID:  <Pine.NEB.3.96L.1030830105202.47993M-100000@fledge.watson.org>
In-Reply-To: <20030829235521.T25083@alpha.yumyumyum.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Fri, 29 Aug 2003, Kenneth Culver wrote:

> > Might devfs propagate ACL characteristics via /dev nodes into
> > applications? Otherwise, the symptom you described would have made me
> > point to the IP firewall first.
> 
> My machine that was showing the problem didn't have a firewall enabled. 
> I'll still mess with it some more to see what I can come up with, maybe
> it was the firewall, but I don't remember having ipfilter or ipfirewall
> in the kernel but it'd been a while since I edited that config file or
> compiled that kernel so maybe I took out the firewall options and never
> compiled, and then compiled today. (It's been about a month since I did
> anything kernel related on that machine). Anyway, when I pinpoint the
> problem I'll mail the list.

I think I missed the message that this is a response to, but here's an
answer to the question: UFS_ACL controls only the introduction of ACL code
into UFS1 and UFS2 file systems, and enables conditional use of ACLs code
if the ACLs flag is set on a file system.  If the ACLs flag is not set on
a file system, the UFS1/UFS2 code is intended to run along its original
permissions-based code path.  Devfs isn't based on UFS, and so it should
be unaffected by the UFS_ACL flag.  If there's a definite causal
relationship between UFS_ACL and the nmap failure, I can't help but wonder
if it's a result of a timing, code layout, or memory allocation change of
some sort.  I wouldn't rule out a bug in the ACL code, but it seems
somewhat unlikely as, without the ACLs flag set, the code path in the UFS
code should be minimally changed... 

The best path to track this down is to try to figure out for sure which
system call is failing, compare expected vs. wire network transmissions,
and see if we can reproduce this in a simpler test program.

We've recently made some changes in how the permissions of new objects are
calculated using ACLs; they were made somewhat before the gcc changes, I
believe, but it might also be interesting to see test cases from before
both changes, in between the changes, and after both, to confirm that it
was definitely the gcc change that kicked off the problem, rather than the
UFS change.  Finally, I'd like to know what, if any, optimization flags
you're using for the kernel compile...

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Network Associates Laboratories




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030830105202.47993M-100000>