RE: windows-NT/pwd.c - struct passwd - Home Directory

[Conrad T. Pino]

Hi Derek,

> From: Derek Price
> 
> >What I don't understand is why "." is a reasonable home directory according
> >to the "getpwuid" implementation:
> >
> > static char *home_dir = "."; /* we feel (no|every)where at home */
> 
> I don't agree that it is.  I think it was a poor, arbitrary
> implementation decision at some point in the past before Windows had the
> concept of a home dir, which did not show up until NT, I believe.

Thank you.  We agree "." is arbitrary and not particularly useful.

> >My thought was along the lines of:
> >
> > struct passwd *
> > getpwuid (int uid)
> > {
> > pw.pw_name = getlogin ();
> >- pw.pw_dir = home_dir;
> >+ pw.pw_dir = get_homedir ();
> > pw.pw_shell = login_shell;
> > pw.pw_uid = 0;
> >
> > return &pw;
> > }

I concluded "get_homedir" wasn't suitable in the above case because
"get_homedir" in "src/filesubr.c" processed the "HOME" variable.

I created "woe32_home_dir" in "windows-NT/woe32.c" to provide only
the Windows view of the home directory and kept the delegation of
"HOME" processing within "get_homedir".  The "windows-NT" versions
of "getpwuid" and "get_homedir" both rely upon "woe32_home_dir".

> If the getpwuid function in windows-NT/pwd.c worked, then the
> get_homedir in src/filesubr.c might be moved into src/subr.c and shared
> with the Windows implementation, or so I was thinking.

We agree on the implied goal of reducing code redundancy.

I wasn't aware "src/subr.c" was a possibility for merging back code.
I'll consider "src/subr.c" when making future prospsals.  Thanks!!!!

The commits I've bring a "get_homedir" migration to "src/subr.c" within
the possible on Windows.  The issue then becomes:

        H:\Conrad\Projects\cvs-1.12-edit>grep -dn "get_homedir" filesubr.c
        File emx\filesubr.c:
        703     get_homedir ()
        File os2\filesubr.c:
        755     get_homedir ()
        File src\filesubr.c:
        803     get_homedir (void)
        File vms\filesubr.c:
        907     get_homedir ()
        File windows-NT\filesubr.c:
        767     get_homedir (void)

        H:\Conrad\Projects\cvs-1.12-edit>

what to do about "(emx,os2,vms)/filesubr.c" versions.  Unless you know
these are a slam dunk right now, I suggest deferral until I complete
the items I've begun.

> Regardless, I do think this basic idea is correct.  My reconsideration
> is that perhaps all user-settable environment variable references,
> should be in get_homedir, and getpwuid would need to return the "secure"
> home directory, as it is defined to on UNIX, where it is often read from
> the /etc/passwd file, for instance.  The closest thing might be the
> value from the registry on Windows.  Windows must read this from
> somewhere in order to set USERPROFILE, HOMEDRIVE, and HOMEPATH on boot. 
> You need to read the Windows specifications and determine where these
> values are coming from to implement this correctly.  Is there no
> equivalent to this function on Windows, where the home dir value may
> have come from a domain server or whatever?

I believe this is the Windows research starting point:

http://msdn.microsoft.com/library/en-us/dnanchor/html/securityanchor.asp

As you might surmise it's a substantial amount of material.

I suggest finishing the "simple" reorganizing I have in progress and I'll
make sure your suggestion is implementable.  

> The UNIX specification for getpwuid is here:
> <http://www.opengroup.org/onlinepubs/009695399/functions/getpwuid.html>.
> 
> >Another thought can take use one step closer to using "src/filesubr.c"
> instead
> >of "windows-NT/filesubr.c" by defining "wnt_homedir" in "woe32.c":

Already implemented as "woe32_home_dir" in "woe32.c" file.

> This would be fine if we decide the proper place for all env var lookups
> is in get_homedir.

This question is on the border between CVS and platform.  I don't know CVS
internals well enough to risk an opinion.  I look to you and CVS developers
to impose requirements the platform compatability layer must meet.

I've seen enough to conclude that non UNIX/POSIX compliant expedient hacks 
eventually become problematic later.  Your work with "GNULib" has focused
my ideas for contributing towards using "windows-NT" project to fill in the
missing UNIX/POSIX functionality "GNULib" requires and Microsoft doesn't
provide.

> >A grep of "get_homedir" usage (below) leads me to believe that whichever way
> >we choose, functions "getpwuid" and "get_homedir" should present a
> consistent
> >view of where the home directory is on a given platform.
> 
> Once again, to summarize, if getpwuid is to be implemented,
> functionality should be divided as follows:
> 
> getpwuid: to POSIX spec as much as possible, secure source if possible,
> output not user settable
> get_homedir: to CVS requirements, uses env vars, possibly set by user

I accept the requirement in principle but I don't see the path to a complete
implementation right now.  I'm sure I'll see more as we move forward.  I will
review your reply to my report on Windows 2000 behavior which I'm aware of but
is unread as I write before commenting in depth.

I plan to finish what I can see which is a shallow compatibility layer with
a compliant API providing acceptable behavior that may deviate from the ideal.
Once there's consensus the compatibility layer provides the required coverage
then I return to reducing behavior deviations that CVS uses and then perhaps
proceed with implementing the ideal for educational purposes and/or donating
to other projects.  I won't commit deviations unless they're existing legacy
behavior.  My goals are maintain existing behavior while committing improved
API which in turn simplifies the task of improving behavior.

My ideas for the API are UNIX/POSIX specifications are non-negotiable and
internal APIs below that are discardable upon discovery of the better way.

> You should be able to get POSIX specs for the other functions in
> windows-NT/pwd.c from opengroup.org as well.  Try changing the
> "getpwuid" in the URL above to other function names as needed.

Will do.

> Regards,

Ditto,

Conrad