Re: windows-NT/pwd.c - struct passwd - Home Directory
Conrad T. Pino wrote: >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. > > Basically. In theory, you could take up desired changes with the POSIX spec with IEEE. Of course, if you did get some changes through, it would likely be years before we could support them fully in CVS and GNULIB - that doesn't happen until it is determined that hosts which require older (i.e. POSIX2) specifications are no longer reasonable porting targets. As an example, GNULIB and CVS both still support ANSI C89 specifications. I would not hazard a guess as to when C99 will be judged a reasonable assumption. GNULIB just finally dropped support for SunOS 4.1.4, about a year and a half after Sun did. Of course, the official policy of GNULIB is to drop support when the provider of the OS does, but it isn't always noticed right away. Also, for a traget like Windows, compliance may be "as close as possible" to the POSIX spec. Sometimes a POSIX spec will make reference to other POSIX specs, and if, for instance, the getpwuid spec referenced the /etc/passwd file directly, we might only be able to approximate the desired result. What you and I are debating, I think, is what is morally closest to the POSIX spec on Windows. As an aside, it might sometimes be interesting to look at what Cygwin did in some of these cases. Their code is GPL'd. Of course, I've looked at it before, and it tends to be much too involved to import into CVS easily - they have their own userid system overlaid on top of Windows, for instance, which would likely make getpwuid a challenge to import, and similar things happen with their file descriptor implementation, but something like their implementation of usleep() or nanosleep() might not have so many internal dependencies. Cheers, Derek ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: windows-NT/pwd.c - struct passwd - Home Directory
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:
> .
>
> >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
Re: windows-NT/pwd.c - struct passwd - Home Directory
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Conrad T. Pino wrote:
>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.
>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;
> }
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.
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?
The UNIX specification for getpwuid is here:
.
>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":
This would be fine if we decide the proper place for all env var lookups
is in get_homedir.
>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
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.
:)
Regards,
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCnI8ILD1OTBfyMaQRArjFAKCEmq0ApQTuiZKSjEIAsR/q2D/DNQCfW6sq
hERtcrUGiZhhgTBwUBWNhKE=
=62BD
-END PGP SIGNATURE-
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
