Proc does not need to be fixed, because /proc is referring to a file
inode.
And due to the fact that it's being presented in /proc as an fd, you
treat it
as an fd, therefor your expectations do not match.
Your assumptions is; because you accessed the world writable file via
a read-only fd, you also expect the file to appear as read-only in /
proc.
There is the mis-match.
The idea of /proc is to refer to files being opened by the process,
while RETAINING the original INODE attributes, regardless of the fact
that
this particular process accessed the file via read-only access.
You are expecting transactional behavior in /proc, where /proc only
registers object information.
I think this discussion had never existed if they used another name for
the 'fd' placeholder in /proc... Because then you wouldn't linked the
/proc fd to the fd being used within the actual process space.
And I think you would agree about your mis-interpretation earlier if
not so
many people had the same mis-interpretation of the virtual /proc
mechanism
(I hope you don't get me wrong; I'm not taking this personal or being
rude to you,
because that's definitely NOT my intention).
Best regards,
Marco
On 30 okt 2009, at 18:38, Pavel Machek wrote:
> Hi!
>
>> Your assumption that the same file descriptor is being re-opened is
>> wrong!
>> The file descriptor retrieved via /proc is a new one. It is not the
>> same as the
>> initial read-only.
>
> True, we were just being sloppy with the words. But it does not matter
> one iota.
>
>> As Martin Rex already explained yesterday, /proc is all virtual.
>> The item referred as fd in /proc is not a real file descriptor and as
>> of that, that 'not-tfor-real file descriptor' is also not re-opend
>> and so does
>> not become read-write.
>
> True.
>
>> Imagen:
>> - a house surrounded with a fence with all doors unlocked (file with
>> perm 0666)
>> - a drive-way leads to the gate in the fence and the gate is
>> unlocked (dir with perms 777)
>> - next we put a lock on the gate and don't give guest the key (dir
>> with perms 700)
>> - guest cannot access the house because he can't pass the gate
>> - now we take an airplane and parachute guest straight into the
>> perimeter of the fence (/proc access)
>> - guest can access the house (write the file), because the house has
>> all doors unlocked
>
> Exactly, and I'm saying that airplanes should not exist (fix the
> /proc). Martin Rex had another solution -- allow fcntl() to remove
> read-only and append-only limitations, so that behaviour is at least
> explicit.
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Proc does not need to be fixed, because /proc is referring to a file
inode.
And due to the fact that it's being presented in /proc as an fd, you
treat it
as an fd, therefor your expectations do not match.
Your assumptions is; because you accessed the world writable file via
a read-only fd, you also expect the file to appear as read-only in /
proc.
There is the mis-match.
The idea of /proc is to refer to files being opened by the process,
while RETAINING the original INODE attributes, regardless of the fact
that
this particular process accessed the file via read-only access.
You are expecting transactional behavior in /proc, where /proc only
registers object information.
I think this discussion had never existed if they used another name for
the 'fd' placeholder in /proc... Because then you wouldn't linked the
/proc fd to the fd being used within the actual process space.
And I think you would agree about your mis-interpretation earlier if
not so
many people had the same mis-interpretation of the virtual /proc
mechanism
(I hope you don't get me wrong; I'm not taking this personal or being
rude to you,
because that's definitely NOT my intention).
Best regards,
Marco
On 30 okt 2009, at 18:38, Pavel Machek wrote:
> Hi!
>
>> Your assumption that the same file descriptor is being re-opened is
>> wrong!
>> The file descriptor retrieved via /proc is a new one. It is not the
>> same as the
>> initial read-only.
>
> True, we were just being sloppy with the words. But it does not matter
> one iota.
>
>> As Martin Rex already explained yesterday, /proc is all virtual.
>> The item referred as fd in /proc is not a real file descriptor and as
>> of that, that 'not-tfor-real file descriptor' is also not re-opend
>> and so does
>> not become read-write.
>
> True.
>
>> Imagen:
>> - a house surrounded with a fence with all doors unlocked (file with
>> perm 0666)
>> - a drive-way leads to the gate in the fence and the gate is
>> unlocked (dir with perms 777)
>> - next we put a lock on the gate and don't give guest the key (dir
>> with perms 700)
>> - guest cannot access the house because he can't pass the gate
>> - now we take an airplane and parachute guest straight into the
>> perimeter of the fence (/proc access)
>> - guest can access the house (write the file), because the house has
>> all doors unlocked
>
> Exactly, and I'm saying that airplanes should not exist (fix the
> /proc). Martin Rex had another solution -- allow fcntl() to remove
> read-only and append-only limitations, so that behaviour is at least
> explicit.
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[ reply ]