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.
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
