Re: PATCH: NSPathUtilities etc

[Alexander Malmberg]

richard@tiptree.demon.co.uk wrote:
> I believe we should try to make sure that the temporary directory *is*
> secure, and document this behavvior, [snip]

Strongly agreed. I think that the documented secureness of GNUstep's
NSTemporaryDirectory is a very valuable feature.

Sheldon Gill wrote:
[snip]
> Consider also, if a user activates a worm/virus/trojan or a buggy application
> then it can access all the files in the 'secure' directory. This hole can be
> avoiding by using an appropriate ACL, file locking or capability mechanism.

We're primarily trying to protect users from other (unpriviledged)
users. Protecting a user (account) from himself is much trickier.

> > > Firstly, the existing code isn't really secure. You can circumvent it.
> >
> > Then that should be fixed. How is it broken?
> 
> Create /tmp/alexander with 0777. Anyone with local access can do it...

True, the secureness check should be repeated for the subdirectory. I'm
currently testing a patch that fixes this and tightens the check.

[snip]
> Also: try replacing NSTemporaryDirectory() with an implementation returning
> 'nil' and running applications.  Watch things break in interesting ways...

That's true, so I'll suggest a slight change in NSTemporaryDirectory's
interface: If no secure temporary directory can be found, raise an
exception instead of returning nil.

[snip]
> The first two are there for a unix domain socket based implementation of
> message ports. Under Darwin and OpenStep it's actually a Mach port wrapper.
> The key functionality is local IPC and there are other more efficient methods
> on many platforms.

Well, additional concrete NSPort classes are a possibility, but they
wouldn't replace the current implementation until they're actually
better. As for efficiency, consider:
http://www.lisp-p.org/throughput/throughput.html (as always, lies, damn
lies, benchmarks). It's the NSPortNameServer part that's tricky, though.

OTOH, if there are platforms (ie. windows :) that need a different
implementation, it might be useful to make NSMessagePort abstract and
move the current implementation to a concrete subclass of it.

> We can easily address the requirements for the NSMessagePort implementation in
> this cycle as part of the "upgrade".
> 
> As for other applications:
> StepTalk calls it in one place.
> ProjectCenter uses it for the rootBuildPath, in one place.
> GWorkspace uses it for the PdfViewer. It's handling of temporary files needs
> more careful consideration from a security persective. Probably
> non-exploitable anyway.
> EasyDiff calls it in one place for a single temporary file.

Most applications aren't in the core repository. A quick grep through my
collection of apps shows that it's used by Addresses, GNUMail, GPSText,
Pantomime, WebKit, and zillion. Importantly, GNUMail uses it a lot,
including for communication with gpg.

- Alexander Malmberg