Re: Adding KAUTH_DEVICE_TTY_ATTACH_<TYPE>

[Iain Hibbert <plunky%rya-online.net@localhost>]

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.

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.

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

iain