The general understanding by users, be it right or wrong, is that whenever = a files' permission is changed, then the effect is immediate everywhere in = the system. This wrong metal model _could_ result in malicious access to a file. I merely wanted to bring the issue to your attention. - p=E9tur On 14/04/2013, at 02:33, Dirk Engling <[email protected]> wrote: > On 13.04.13 20:29, P=E9tur Ingi Egilsson wrote: > = >> I noticed that if I execute the following code, then the program is >> able to read the file even if the files' permissions are changed around >> the /mark/ section in such a way that the UID under which the program is >> running should not have any permission to read the file. >> = >> This is not a desirable behaviour. >> How can I prevent this behaviour on my system? > = > P=E9tur, > = > you may have a wrong understanding of what the difference between a file > and its names is. The moment you open a file, the system call checks the > permissions and if you are allowed to read the file, returns another > name for your file, the fd. I am aware of the difference. > = > If you change permissions on the file name in the file system, your file > descriptor is not affected. The overhead for chasing changes in your > directory structure (and nothing else is changing permissions) on every > read() system call would just not be bearable. Understood. > = > You can even delete the file from the file system and still reference > the content by your descriptor. Only when the last name of your file is > gone (i.e. you fclose your descriptor) the file is actually removed from > the file system > = >> fd =3D fopen(argv[2], "r"); > = > I am pretty sure, this should rather read argv[1] Indeed. > = > erdgeist _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"