hurd-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PID of client requirements


From: Thomas Bushnell, BSG
Subject: Re: PID of client requirements
Date: 06 Nov 2002 15:52:40 -0800
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Marcus Brinkmann <address@hidden> writes:

> You are indeed missing the point.  I am not talking at all about how to do
> such things cleanly and nicely.  My example was deliberately arbitrary, but
> carefully set up around the following assumptions:
> 
> 1. The manager program lives entirely in the POSIX world and doesn't know
>    about the Hurd at all.
> 2. The rogue task lives in the Hurd world and knows about such dirty tricks
>    like that the PID can be set to anything.
> 
> A POSIX program would not send messages, it would just use kill().  It could
> rely on the information provided by GETLK that the process ID is valid and
> always equals the process ID of the process having the lock, because that is
> what the standard says.  

Ok, so the manager program is not something *we* are writing, but
something that people commonly do write, using only Posix facilities,
for particular cases, and in which they rely on this facility?

> In the Hurd world, the rogue process could insert the PID of the root
> filesystem, leading to a desaster.  So a small bug in the POSIX world would
> be a grave bug in the Hurd implementation.

I think I see now.  

> Now, the above locking example is not the ideal example, in that it relies
> on a bug in the first place to illustrate the problem.  Lock files should
> not be readable or writable to untrusted users.  But that is only the best
> example I came up with so far.  I am worried that there are similar or worse
> problems hidden.

Oh, I can imagine reasonable manager processes that would allow a
general access to a lock file.


Such cases, it seems to me, mean that we probably do need some kind of
PID validation.  I'm not sure what the right strategy is, but I'll try
and think of some.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]