svn commit: r263755 - head/sys/kern

[David Xu]

On 2014/03/29 11:25, Mateusz Guzik wrote:
> On Sat, Mar 29, 2014 at 11:09:34AM +0800, David Xu wrote:
>> On 2014/03/29 10:56, Mateusz Guzik wrote:
>>> But this patch would mean that current consumers (if any) would break -
>>> just calling FIOASYNC would not result in receiving SIGIO.
>> The old behavior is inconsistent with other piece of code in the kernel and
>> may be incompatible with POSIX.
>>
> Oh, I didn't know that. Unsure what to do in this case.
>
>>> Original patch by Don seems to work fine though, but I'm unsure about
>>> one thing (present in this patch as well):
>>>
>>> There is one devsoftc.sigio instance and one can get multiple processes
>>> with devctl fd. Is it safe from kernel perspective to have multiple
>>> processes call fsetown(*(int *)data, &devsoftc.sigio)?
>>>
>> There is an inuse variable guarding this problem, you can not open it
>> multiple times, you can only do it in the forked process which inherited
>> the fd. if you don't trust the child process, you can close it before
>> executing real code in the child process.
>>
> This does not answer my question.
>
> I can easily imagine devctl extended in the future so that there are
> per-jail instances (could be handy to monitor e.g. vnet related events
> like link changes).
>
> If fsetown handling like this is insecure this would bite us in that
> scenario (and few others). In short, if we can avoid giving another way
> to corrupt stuff in the kernel to userspace, we should.
>
I can not see what you said, where is the security problem with fsetown ?
if you have per-jail instance of devsoftc, they all are operating on their
own instance. but I don't think this patch should address jail now, there
are many things are not jail ready.