Hi Tim,
Let me add that the above security bridge is not only manifested when
you set the {{ atomically: YES }} but also when you do not use this
feature!
Torli
On Tue, 2009-03-17 at 19:18 -0400, Torli Birnbauer wrote:
> On Tue, 2009-03-17 at 23:38 +0100, Tim Kack wrote:
>
> > Hi all,
> >
> > Yes - I am not sure if this is intended behavior or not.
> > The file is created/written to like this:
> > 1. Create a unique file
> > 2. Write string to that file
> > 3.Using glibc Rename function to rename the unique file to the old
> > file. (NSData.m:1054)
> > 4. Set the attributes on the new unique file
> >
> > The docs for rename(const char *oldname, const char *newname)
> > function says that:
> > "If oldname is not a directory, then any existing file named newname
> > is removed during the naming operation."
> > I tried to figure out what is _intended_ to happen but I have not
> > found anything so far.
> >
> > I will open up a bug on Savannah.
> >
> > // Tim
> >
> > 2009/3/17 Torli Birnbauer <[email protected]>
> >
> > I have just started to learn the GNUstep's development
> > environment and I have in my very first program stumbled
> > across a serious security problem in the way Objective-C
> > handles IO. Obviously, Objective-C does not honour Unix file
> > permissions. You can reproduce this problem on Unix/Linux
> > systems by setting {{ chmod 000 /some/dir/your.data }}, and
> > then run the example program in the GNUstep documentation
> > page (Base Programming Manual/The Objective-C Language)
> > under "2.8.5 Loading and Saving Strings" by setting the path
> > to {{ /some/dir/your.data }}.
> >
> > Torli
> >
> > _______________________________________________
> > Discuss-gnustep mailing list
> > [email protected]
> > http://lists.gnu.org/mailman/listinfo/discuss-gnustep
> >
> >
> >
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
