[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSBundle -initWithPath: warning
From: |
David Ayers |
Subject: |
Re: NSBundle -initWithPath: warning |
Date: |
Fri, 01 Apr 2005 11:30:26 +0200 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 |
Sheldon Gill wrote:
Why is the code checking for an absolute path? It is superfluous and is
more likely to cause problems than solve them.
I kind of agree that this seems superfluous. If there is a reason, we
need some documentation.
Later on, it checks that the bundle directory is readable. Why?
This may have a reason wrt to setuid programs. A file may be detected
as non readable/writable because the real uid's don't match but actually
is readable/writable because the actual access is done with the
effective uid.
I'm not 100% sure about this behavior and whether we should be checking
or not. I've had warnings that defaults couldn't be created because of
this, even though they could have. But I'm not clear about the
intention of this feature within GNUstep in relation to access()
...
#include <unistd.h>
int access(const char *pathname, int mode);
...
The check is done with the process's real uid and gid,
rather than with the effective ids as is done when actuÂ
ally attempting an operation. This is to allow set-UID
programs to easily determine the invoking user's authorÂ
ity.
...
Surely the better option is to simply make the open calls and handle
failures properly. That much has to be done anyway. Why complicate
matters by doing checks that don't give us any real benefit?
Consider 1: If the path isn't absolute it may still work in some cases.
In the cases it doesn't work, it'll fail to find the file because the
path is incorrect. Just like it'd fail if the path was otherwise incorrect.
Consider 2: if the bundle directory is unreadable, it'll fail when we
try to read it. Try to read it and handle not being able to.
I don't necessarily disagree, it's just that we should be clear about
what we want and document it.
I'm leaning to not checking in the general case but explicitly check
where we have concerns in the setuid case, which would probably move
most of the checking responsibility to the application and out of -base.
But how to treat user defaults here is not crystal clear to me.
Cheers,
David
- Re: NSBundle -initWithPath: warning, David Ayers, 2005/04/01
- Re: NSBundle -initWithPath: warning,
David Ayers <=
- Re: NSBundle -initWithPath: warning, Richard Frith-Macdonald, 2005/04/01
- Re: NSBundle -initWithPath: warning, Sheldon Gill, 2005/04/01
- Re: NSBundle -initWithPath: warning, Richard Frith-Macdonald, 2005/04/01
- Re: NSBundle -initWithPath: warning, Sheldon Gill, 2005/04/02
- Re: NSBundle -initWithPath: warning, Richard Frith-Macdonald, 2005/04/02
- Re: NSBundle -initWithPath: warning, Pete French, 2005/04/02
- Re: NSBundle -initWithPath: warning, Richard Frith-Macdonald, 2005/04/02
- Re: NSBundle -initWithPath: warning, Markus Hitter, 2005/04/02