@ub and @cb issues - an idea

[Fairlight]

With neither thought nor caution, Jay Ashworth blurted:
> My followup would be, if something like this *is* implemented, that to
> turn it on, you ought to have to set PF_ENABLE_UNSAFE_WINDOWS_UID to YES or
> something similar that puts the responsibility squarely in the
> administrators lap.  We call it a 'conscious act', in the security
> business, and the snarky name of the suggested variable is the *main*
> part of it.

Anyone even remotely following the plethora of Windows patches released
lately should realise that a filePro username scheme of this sort is the
-least- of the OS's security issues--not that I consider it irrelevant.
But it's rather like complaining about a nick in the paint job on your car
when the windshield is cracked, two doors are missing, the hood won't
close all the way, the transmission leaks fluid like a sieve, and the head
gasket is shot.  There are just more pressing issues.

Anyone who's security conscious about their production systems has them off
of 'doze--or I suppose could be putting in the time patching them to death.
There are -so many- holes in it though, that it's really like sticking a
finger in the dike.

I consider a request like this UID workaround a lot less of a security
risk than hearing about AnzioWin shipping with pass-through remote command
execution turned ON by default, and being told that because they know
how the majority of their customer base uses it on "trusted systems"
(ha!...all here who believe in such a thing, raise your hands), it wasn't
worth changing the default to require a conscious act to enable it.  I'm
waiting for reports of a malicious /etc/issue.net that contains a DELTREE
/Y command embedded in it.  Maybe then people will consider such defaults
an issue.

That's potentially far more harmful to a system than what Steve proposed.
(Not that I think it's at all a good idea--that proposal.)

The Good Idea[tm] is to move to an OS that doesn't have as many holes as a
colander, and thus render the entire discussion moot.

YMMV.  I'm not out to start an OS war.  Quite the contrary--I consider the
whole issue of the security of such a proposal a moot point from a security
standpoint, strictly -because- it's no secret what 'doze is like.  Implement
it or no; it won't make much of a difference.  Those still running 'doze
in production environments either know what they're doing and put in the
effort, or they're ready to face the risks--or should be.  And as M$ is
just releasing patches that affect serious core security considerations as
far-reaching as back to Win98, I see it as not really mattering how much
effort one puts into it--patched to the latest still isn't good enough, and
hasn't been for years or 98 would have been patched far earlier than six
years later.

Long story short:  If you want *nix functionatlity, run *nix.  It doesn't
get much simpler than that.

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html