On Fri, Jul 11, 2008 at 09:37:41PM -0500, Mike Gerdts wrote: > On Fri, Jul 11, 2008 at 4:53 PM, Nicolas Williams > <nw141292 at sac.sfbay.sun.com> wrote: > > o Unix username (pw_name, sp_namp) is taken from the value of the > > "samAccountName" AD attribute of the user object, qualified with > > the name of the domain in which that object resides (e.g., > > "foo at example"). > > If the AD samAccountName does not conform to traditional UNIX account > naming semantics, how is this handled? As of snv_91, passwd(4) > indicates that warnings will be issued when usernames that don't > adhere to the UNIX tradition are encountered. Would this proposal > relax the limitations documented in passwd(4) or would only a subset > of valid AD usernames be supported?
passwd(4) says a warning will be displayed, but it doesn't say what tool would display the warning (login(1)? useradd(1M)? w(1)? ls(1)...). I believe it would only be sensible to emit a warning on user creation. We're not providing user account / group administration tools for AD. Therefore there's no chance for us to emit such a warning. > For instance, AD and Windows allow samAccountName to contain a string > that looks like a 9-digit number. While a 9-digit number as a > username works in Solaris (at least as far back as Solaris 8) with > very few real issues, it has been an unsupported username from the > standpoint of Sun and some ISV's that provide software on Solaris. We could impose some constraints, though not, for example, on username length (issues w.r.t. username length are orthogonal to this case, though we'll likely undertake some small projects to relax user/group name legnth constraints in Solaris). But I'd much rather we don't. Keep in mind a couple of things: a) you're already free to violate many user/group naming constraints in various existing name service backends, and little is done about this (aside from username length restrictions in some tools, I can't think of any right now), and b) because of PSARC/2008/342 we already have the ability to display such odd user/group names in contexts where you'd expect a regular Unix user/group name. It is still not wise to name users/groups in AD which might cause problems for Solaris or various applications, such as all numeric user/group names, names that start with '-', names that contain ':', names that contain non-printing or non-ASCII characters, ... It might be useful to have the name service switch filter or escape such names. And it may be nice to setup a convention that the name service switch and the backends use UTF-8, or enhance the relevant interfaces to specify codesets, and then ensure that getXbyY() callers get names that have been converted to their current locales' codesets. But such changes to the name service switch and friends are not this case. Nico --
