discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Creating NSImage in a tool


From: Richard Frith-Macdonald
Subject: Re: Creating NSImage in a tool
Date: Thu, 16 Feb 2006 07:29:57 +0000


On 16 Feb 2006, at 03:37, Alex Perez wrote:

Sheldon Gill wrote:
Stefan Urbanek wrote:
Hi,

I need a tool that will take some inputs and will generate one or more TIFFS. I
am trying to create an image in a tool under MS Windows like this:

[snip]

The output is:

2006-02-13 15:10:14.000 test.exe[3512] Drawing path
The file 'c' is writable by someone other than its owner.
Ignoring it.
There is code in base which enforces a particular security policy.
It seems the security policy on your system violates those expectations. The specific issue is that your configuration file 'c' has permissions on it that base doesn't like. My recommendation is removing the offending code: gnustep-base NSPathUtilities.m ~line 660

If this causes problems *under windows*, shouldn't it be ifdefed out *under windows*?

In plain english, I think what Sheldon is saying is that the doesn't think the base library should check whether the config file it is reading in could have been hacked by someone else or not. If so, I strongly disagree with him on this ... if you read in a config file which tells you where programs are located, and someone has hacked that to point to a trojan, you have a big security issue, so this sort of checking is essential. It is not sufficient to say that developers should add other checks of their own devising (of course that would be good) ... you have to try to minimise security problems at every point. So the 'correct' advice would have been to locate and protect this config file such that only the owner could modify it, so that the check would not fail. Hacking the source as suggested would be a last resort IF Stefan want insecure code.

Of course it's never quite that simple ... you have filesystems which by design cannot be made secure ... do we just say config files are not supported on such filesystems? It's a reasonable answer, but debatable. On windows you also have the problem that the security model is not the same as the posix/unix one, and it's possible to have things secured by access control lists even though they appear insecure when you look at posix file modes ... it's a bug that the base library does not check this (and I would love someone to contribute the code to do so) ... but that's a reason to fix the bug, not a reason to make the code less secure.

I'm not sure whether the NSFileManager - fileAttributesAtPath:traverseLink: method should, on windows, check ACLs and modify the filePosixPermisions it returns based on ACL restrictions, or we should only do those checks for a few special cases.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]