> > > We can check if we're in the global zone in the smf start method
> > > (console-login); if not, disable all virtual console instances.
> >
> > In general services are delivered disabled. It would seem
> > more appropriate to enable the virtual instances when configured
> > rather than disable them where inappropriate.
>
> We don't ship a system with the console itself disabled by default, do
> we? ;-}
No, however I suspect that the VT design requires that more than
a virtual tty be present.
> For ease of use, I'd rather see virtual console instances created and
> started when invoked from the keyboard, if that's at all possible.
Yup, that would be my preference. Like clone devices ;-)
While I didn't comment earlier, one of my comments on the thread
of console-login vs. vtconsole-login was going to be something
like: It seems to me that services instances can be created/deleted,
enabled/disabled independently of other instances, so why is
vtconsole-login different?
> Having to preconfigure a set number of them feels way too much like
> the bad-old-days of BSD pseudoterminal allocation. Plus, the point
> where I'll need these things is almost certainly precisely the point
> where I'll be unable to start any.
Yup, lived through them as well.
> What is the security issue that's fixed by forcing explicit allocation
> of individual virtual console instances?
IIRC, whether or not security is involved the Greenline policy
is that services not deliver enabled unless needed in the seed,
but be enabled by profiles or svcadm equivalents.
> Might that issue be better dealt with some sort of resource limit?
Only if things like clone devices would be resourced. I don't
see it as an issue. Presumably the console user has appropritate
limits that the admin gave to control her actions.
Gary..
