Re: Creating NSImage in a tool

[Richard Frith-Macdonald]

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.