[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
From: dfs at roaringpenguin.com (David F. Skoll)
Subject: Counseling not to use Windows (was Re: Anonymous
surfing my ass\!)
On Mon, 15 Jul 2002, Roland Postle wrote:
> > because of programming errors. Encoding metadata such as "executableness"
> > in a filename, for example, is a fundamental design flaw, and one that's
> > impossible to correct without changing Windows' design.
> Sorry to pick on your example but an extension merly indicates what kind of
> data is in the file.
Not under Windows as it is configured by 99.99% of end-users. If you
name a file "foo.txt", very different things happen if you click on the
file than if you click on the exact same file named "foo.exe".
> A .txt extension suggests that a user might want to
> hand the file to a program that'll treat the file as plain ASCII, similarly
> an .exe extension suggests that a user might want to give the file some
> memory and time slices and treat it as a program in it's own right. You
> could load the .exe into notepad, and you could execute the .txt file.
Again, for 99.99% of end users, such fine points are irrelevant. To them,
clicking on an .exe runs the program. Windows even "helpfully" hides the
extension by default.
> As for the actual security of whether a user /can/ execute a file, Windows
> doesn't seperate 'read' and 'execute' privileges well enough. However it's
> my understanding that's got more to do with the design of the x86 memory
> architecture than Windows' design. Linux just pretends to seperate 'r' and
> 'x' privs because it's a unix clone. I'm prepared to stand corrected on that
> though.
That is true when it comes to memory protection, but what you're
talking about is filesystem protection, and Linux doesn't "pretend"
anything -- it enforces it. I believe it is possible under some
versions of Windows to allow read access but not execute access to
files and directories, but again, 99% of end-users don't know this
and don't configure it.
> I agree completly that Windows does have some fundamental design flaws that
> prevent it being locally secure. A better example might be the ability of an
> application to send messages to another application, apparently without
> regard for who the owner of the target application is.
:-) I'm not familiar enough with Windows to be aware of things like that.
Thanks.
Regards,
David.
Powered by blists - more mailing lists