[2440] in Kerberos-V5-bugs
krb5-admin/176: glob vs. regexp in kadm5 library
daemon@ATHENA.MIT.EDU (bjaspan@MIT.EDU)
Tue Nov 12 13:06:49 1996
Resent-From: gnats@rt-11.MIT.EDU (GNATS Management)
Resent-To: bjaspan@MIT.EDU
Resent-Reply-To: krb5-bugs@MIT.EDU, bjaspan@MIT.EDU
Date: Tue, 12 Nov 1996 13:05:05 -0500
From: bjaspan@MIT.EDU
Reply-To: bjaspan@MIT.EDU
To: krb5-bugs@MIT.EDU
>Number: 176
>Category: krb5-admin
>Synopsis: glob vs. regexp in kadm5 library
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bjaspan
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Tue Nov 12 13:06:01 EST 1996
>Last-Modified:
>Originator: Barry Jaspan
>Organization:
mit
>Release: 1.0-development
>Environment:
System: SunOS DUN-DUN-NOODLES 5.4 Generic_101945-37 sun4m sparc
>Description:
This is a feature change proposed for after the 1.0 release.
The kadm5 library currently supports the use of shell-style globs (?,
*, []) instead of regular expressions for the functions that list
matching principal and policy names. I originally made this decision
on the theory that system administrators (at the time, OV's customers)
did not necessarily understand regular expressions and in any case
would rarely have use for the extra flexibility they could provide.
Thus, I went for a simpler interface instead of more flexibility.
I no longer think I made the right decision. Except in cases of
security decisions where application programmers should not be
trusted, the kadm5 api should provide mechanism and not enforce
policy. In this case, "providing mechanism" means offering the most
flexible search capability possible, and clearly regexps win over
globs. There is no security advantage to limiting the expression.
The concern about interface complexity is still valid. However, I
know see that the glob/regexp decision should be made in the
application program, not the api, since then the application can
provide either interface (perhaps glob by defaut, and regexp if you
specify "-re <exp>"). The api already contains a (currently internal)
function to convert globs to regexps, so it can simply expose that
function for applications to use.
I therefore propose the following change. kadm5_get_principals and
kadm5_get_policies will be declared obsolete. Two new functions,
kadm5_list_principals and kadm5_list_policies, will be created that
accept regexps instead of globs. A new function kadm5_glob_to_regexp
will be created as a convenience function for callers wishing to
support glob syntax. The kadmin client will continue to accept globs,
but will also be changed to accept -re regexp anywhere it currently
accepts a glob.
Alternatives to the proposal:
(1) The get_* to list_* change could be accomplished quite trivially
with a new API version number instead of new functions. But I think
list_principals is a better name for the function that get_principals,
since it is returning an array of principal names and not principal
structures, anyway.
(2) The list functions could accept a char * and a boolean indicating
whether it the char * is a glob or a regexp. This would keep the
conversion code inside the api instead of having every client know how
to call kadm5_glob_to_regexp.
>How-To-Repeat:
>Fix:
>Audit-Trail:
>Unformatted:
