BUG: FreeBSD version 5.0.14 (and lower)... setperms

[Fairlight]

Actually, that's been reported directly to fP-Tech, by me, probably over
a year ago, closer to two or three I'd guess--besides being posted here.
I probably have copies of the email.  I brought it up the same time I was
harping on the ridiculously persistant EXPORT default umask that results in
0666 export files.  None of which has changed.

It's not just on BSD.

Small nit--666 doesn't make a file world-removable, just world flushable.
You can't actually -remove- an inode you don't own, but you can flush the
contents nice and clean.  A minor nit, since the effect is the same--as I'm
sure -you- know quite well, but others with less system-level knowledge may
not.  See, the -nice- thing about this vulnerability, for those that aren't
aware, is that someone can not only wipe your file clean, but fill it up
from /dev/random or any other noise generator they like, filling your whole
filesystem, amounting to a disk-based denial of service.  Since -many-
systems I see have /appl sitting in the root filesystem, this tends to
majorly hose things like apache, syslogd, cron, utmp/wtmp...you know,
anything that actually needs to write things to files that may also be in
the root filesystem.  Since a lot of systems still keep /var and /tmp on
the same filesystem, that's a lot of potential hosing due to a little
"oversight".

Anyway...

I thought it should be 0600 as well, although someone brought up something
about menus, and with runmenu being non-suid; that may be a valid point,
assuming it utilises the file.  So okay, 0644 would do.  But the write bits
really should go.

Problem is, -I- reported it directly to fpsupport back when they still
wanted that to be their email address, "...because we like things with fP
in them."  It did no good.  It's not been changed.

If you can get them to change this, -please- get them to change the bloody
EXPORT defaults as well, because telling them has been like talking to
brick for years, and I'm tired of trying.  I've only complained about it
for like three or four years steadily now, and sporadically before that.  I
don't even bother harping on it anymore during audits of fP-centric systems
where exports occur.  I just make the client aware of the inherent risks
and stop bothering to report any files I 100% know are exports.  If they
want to take the risks, that's their call.  Though technically, developers
should stick in a SYSTEM to chmod them, since it's technically viable and
not very expensive.

Point is, it doesn't belong that way at all, and the developer shouldn't
have to think twice about it.  It's THE VENDOR'S RESPONSIBILITY.

There's also a nice little directory that a developer told me gets created
during install.  it was fp/lib/install if memory serves, and it gets 0777
and appears to stay empty.  At least, the developer that informed me of its
origins swore it happened at install.  It doesn't appear on every system I
work with, however.  I've really only seen it on linux installs, but it's
been a while since I worked on a recent SCO install.

Personally, I think they need tighter security more than they need a spell
checker.  "I'm sorry, did I say that out loud?"  --Jack O'Neill

mark->


In the relative spacial/temporal region of
Sat, Apr 30, 2005 at 11:27:10PM -0400, John Esak achieved the spontaneous
generation of the following:
> 
> The setperms function in FreeBSD sets the wrong permissions on the main
> filePro "config" file. It is setting them to 666 which of course makes the
> file world-writable-removable, etc. The entry in the fp.list is wrong. It
> should probably be 644. Actually, only filePro reads/writes this file, but I
> like to be able to get to it in other ways from other processes, sometimes
> not user filepro, otherwise it could of course be 600.

-- 
          *****   Fairlight Consulting's Software Solutions   *****
OneGate Universal CGI Gateway:                  http://onegate.fairlite.com/
FairPay PayPal Integration Kit:                 http://fairpay.fairlite.com/
RawQuery B2B HTTP[S] Client & CGI Debugger:     http://rawquery.fairlite.com/
Lightmail Mail Sending Agent:                   http://lightmail.fairlite.com/
FairView Image Viewer for Integration:          http://fairview.fairlite.com/