Re: File descriptors

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 <[e-mail]> 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

_______________________________________________
[e-mail] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[e-mail]"