solaris /dev/console patch

[John (J5) Palmieri]

On Thu, 2006-04-27 at 10:22 -0400, Havoc Pennington wrote:
> 
> Robert McQueen wrote:
> > On a related note, I would appreciate a better mechanism for making a
> > cleaner system-dependent implementation of this policy. RedHat uses
> > pam_console, but Ubuntu has a pretty heavy patch to instead use their
> > pam_foreground module & lock files to enforce that the at_console policy
> > must also be the currently active tty, which seems to be closer to what
> > this Solaris patch does. I discussed with them a more extensible means
> > of adding policies rather than overloading/retasking the at_console like
> > this, but they deemed the configuration parser too fragile to add a new
> > option without quite a lot of work.
> > 
> > It seems to me like we should think about a better way to achieve this
> > so that we could support more of these policies in a clean way, rather
> > than ending up with either heavy distro or system-specific patching or a
> > load of ifdef'd code.
> >
> 
> Well, if the Ubuntu way still _means_ "at_console" in effect (and 
> doesn't have some different semantic) then using the same at_console 
> config option seems sensible.
> 
> I guess I don't know whether "at_active_console" would be different 
> enough to merit a distinct config option.
> 
> I don't really get why it'd be hard to change the config parser, it's 
> just a straightforward XML parser ...
> 
> Adding not-integrated-upstream config options is probably bad, though.
> 
> Anyway, I don't know about this patch and afaik it's never been 
> submitted, so tough to comment too much ;-)
> 
> In general we've taken distribution-specific stuff, e.g. init scripts, 
> into the upstream source - as long as it's appropriately sorted out in 
> configure.in
> 
> Making this cleaner/less-ifdef'd would be nice, though it isn't 
> transparently obvious to me how to do it. We might want to use 
> all-runtime conditionals and not ifdef, is one approach.
> 
> Havoc

Actually I wouldn't mind moving to the active TTY semantics.  

The biggest problem with the XML parser is the validation which is one
big fragile logic statement.  Every time an option is added one must go
into that statement and figure out where to add the || FOO_OPTION's or
&& FOO_OPTION's and where one must completely restructure the logic.  At
least that is what I remember when writing the at_console patch.  Using
a DTD and validating parser would have been better but I don't even
think we actually work with libxml anymore and on Red Hat/Fedora at we
have move moved d-bus into /bin and /lib which would mean libxml would
have to be moved to /lib (expat is right now) in order to switch.
 
-- 
John (J5) Palmieri <johnp at redhat.com>