Re: Adding KAUTH_DEVICE_TTY_ATTACH_<TYPE>

[Elad Efrat <elad%NetBSD.org@localhost>]

On Wed, Apr 29, 2009 at 9:24 PM, Iain Hibbert <plunky%rya-online.net@localhost> 
wrote:


> Well: setting the line discipline causes the .l_open function to be
> called. In this case its pppopen() which calls pppalloc() which calls
> ppp_create() which creates the new network interface..
>
> (there seems another path where pppalloc() doesn't call ppp_create() but I
> think its a special case where a transfer of ownership is arranged using
> the PPPIOCXFERUNIT ioctl and I'm not sure how that is used exactly,
> perhaps just to offload the IO to another process inside pppd(8) and I
> think its reasonable to expect the other process to have sufficient
> credentials)
>
>> If it adds a network interface, we should be using something like
>> KAUTH_NETWORK_INTERFACE::ADD, but I want to make sure we're not mixing
>> two functionalities of the same device. :)
>>
>> As for the bluetooth code, bcsp and btuart, aren't they doing the
>> same? the man page suggests they're used to implement a tty over
>> btuart/bcsp, which is what lead me to classify them under the "tty"
>> category in the first place...
>
> No, they provide a "tty line discipline" which controls what happens to
> the IO from the serial port which already exists and is attached to a
> /dev/ttyXX node.
>
> What happens is that if the admin determines that a bluetooth controller
> with RS232C interface is attached to the serial port[1], they can manually
> configure a bluetooth device in the system as there is no way to
> autoconfigure a device on a serial line.. and then, the raw IO will be
> passed directly into the bottom end of the bluetooth[2] stack rather than
> out of the tty node.
>
> [1] often the serial port is contained inside the device rather than it
>    actually having an external RS232C lead. This is the case for several
>    PCMCIA/CF devices which attach as com(4)
>
> [2] or the network stack, in the sl(4), strip(4) and ppp(4) cases.
>
>> > Although the sl(4) and strip(4) instances (currently) need to be 'created'
>> > beforehand, it is the act of attaching the line discipline that actually
>> > turns an inactive interface to an active one. Perhaps that requires more
>> > than just a single authorisation step (create => activate => configure)?
>>
>> Suppose we do that, sl/strip get just one authorization call
>> ("activate"), and the rest (ppp, btuart, bcsp) get two ("create" and
>> "activate")?
>
> That would likely work

To summarize, then, we need KAUTH_NETWORK_INTERFACE::ADD + ::ENABLE
(or similar) in ppp, and two more ::ENABLEs in sl/strip. We also need
KAUTH_DEVICE_BLUETOOTH_ADD + ENABLE for btuart/bcsp.

Sounds good? :)

Thanks,

-e.