Re: Adding KAUTH_DEVICE_TTY_ATTACH_<TYPE>

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

On Tue, Apr 28, 2009 at 11:37 PM, Iain Hibbert 
<plunky%rya-online.net@localhost> wrote:
> On Tue, 28 Apr 2009, Elad Efrat wrote:
>
>> On Tue, Apr 28, 2009 at 10:23 PM, Iain Hibbert 
>> <plunky%rya-online.net@localhost> wrote:
>> > On Tue, 28 Apr 2009, Elad Efrat wrote:
>> >
>> >> We have several pieces of code that support attaching a tty. I would
>> >> like to move them away from KAUTH_GENERIC_ISSUSER, and propose
>> >> KAUTH_DEVICE_TTY_ATTACH_ as a replacement, with extensions such as
>> >> SLIP (net/if_sl.c), STRIP (net/if_strip.c), PPP (net/ppp_tty.c),
>> >> BTUART (dev/bluetooth/btuart.c), and BCSP (dev/bluetooth/bcsp.c).
>> >
>> > I'm not sure that this really comes under 'attaching a tty'?
>> >
>> > All of those are more accurately described as attaching a line discipline
>> > but that is somewhat vague as to the permissions needed so perhaps a
>> > better category is 'create a pseudo device' with sub-categories of NETWORK
>> > for sl(4), strip(4), ppp(4) plus tap(4) and gif(4) etc, BlUETOOTH for
>> > btuart(4) and bcsp(4) plus perhaps DISK for vnd(4) and raid(4) and any
>> > other such that I don't know about..?
>>
>> The comments at the top of each function state that they're "attaching
>> a tty to the first available <type unit>". Looking at the code, most
>> just iterate through a list, looking for an entry with a NULL tty
>> pointer, and use it to attach the passed tty.
>
> Mmm - sl(4) and strip(4) do it that way but I think thats a holdover from
> the days when a specific number of device instances were created at boot
> time. They do not have the capability to clone as required and just find
> the first unconfigured interface.

Ugh... yeah. :/

> In bcsp(4) and btuart(4) for example the open() routine allocates a cfdata
> and attaches a new pseudo device instance. Its much the same for ppp(4) so
> far as I can see though its a bit convoluted..
>
>> Why should we call it "create a pseudo device"?
>
> In the ppp case, when you run a program that wants to open a PPP
> connection it creates a new network interface as if an actual network card
> had just been plugged in. Hence a pseudo device is created. Same for the
> bluetooth code and I think its somewhat cleaner that way.

Hm: are you sure the code in net/ppp_tty.c adds a network interface?
from its commit message:

    The PPP kernel code is now split into if_ppp.c, containing generic
PPP support, and ppp_tty.c, which specifically supports PPP on async
tty devices (as a line discipline).

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...

> 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")?

Thanks,

-e.