os.User / os.FindUser

[Brad Fitzpatrick]

I'd like to see User support in package os, similar to Process / FindProcess perhaps.

I figure it could use cgo wrapping getpwent.

I spent some time on MSDN trying to figure out which Windows API do the equivalent but got lost.

Strawman:  (similar to Process / FindProcess)

package os

type User struct {
     Uid, Gid       int
     Username, Name string
     HomeDirectory  string
}

func FindUserName(username string) (*User, os.Error)
func FindUserId(uid int) (*User, os.Error)

Any thoughts, reservations?  Could this work on Windows?

[Russ Cox]

This can't be done with cgo using the current build,
because you need package os to build cgo.
(In contrast, you don't need package net to build cgo,
so you can require cgo to build package net.)

It would also mean that every Go binary ends up
depending on glibc. I don't know that I am ready
for that yet. I think it's likely we'll get pushed there
eventually but I'd kind of like to avoid it as long as
possible.

If it were a separate package then everything
gets easier.

Russ

[Brad Fitzpatrick]

I'm happy with any of:

 

a) package os.FindUser simply parsing /etc/passwd by default and not using getpwent (and thus no NIS, LDAP, etc)

b) putting this in a different package.

c) a + b. having a) do the simple thing, but letting an empty import of b) register with package os better lookup functions.

Preference?

[Rob 'Commander' Pike]

On Wed, Apr 20, 2011 at 10:15 AM, Brad Fitzpatrick <brad...@golang.org> wrote:
> I'm happy with any of:
>
> a) package os.FindUser simply parsing /etc/passwd by default and not using
> getpwent (and thus no NIS, LDAP, etc)

this means someone will need LDAP lookup, another parallel package
will be born, and we'll have more confusion. let's get it right, or at
least lay down a design that can adapt to being right.

> b) putting this in a different package.

yes.

> c) a + b. having a) do the simple thing, but letting an empty import of b)
> register with package os better lookup functions.

that's too fiddly and mysterious.

-rob

[Brad Fitzpatrick]

On Wed, Apr 20, 2011 at 10:20 AM, Rob 'Commander' Pike <r...@golang.org> wrote:

> b) putting this in a different package.

yes.

Any package + struct naming suggestions to avoid stuttering?

 

[Rob 'Commander' Pike]

thinking out loud, not near a proposal,

how about
os/user

type User struct

then you stutter user.User, but rarely because in return you get
Lookup(string) (*User, os.Error)
LookupId(int) (*User, os.Error)

and you see things like

u, err := user.Lookup("bradfitzcarraldo")

the problem is that 'user' may be too good a name to take away by
making it the package name. it might make sense to pluralize the
name, although i don't like that precedent.

-rob

[brainman]

Don't know much about security, so I might be wrong on many accounts. What I do know, it is a big can of worms.

Uid: equivalent on Windows would be SID (http://en.wikipedia.org/wiki/Security_Identifier), it is certainly bigger then int;

Gid: I don't think there is such thing, user just member of many different groups;

Username, Name: are probably OK;

HomeDirectory: users in Windows are generally part of "domain" group of computers, but on every single computer user does have directory where they keep their files, more often then not these files are just settings/configs, but files user actually work with (document, program source) are kept somewhere else. I certainly not called "home directory", for example on my PC, it is called "C:\Documents and Settings\brainman";

FindUserName: LookupAccountName would, probably, be equivalent - please, note that all calculations are done relative to "domain name" or "pc name", username is always a tuple of "domain or computer name" + "user name".

Alex

[Brad Fitzpatrick]

What if these are defined, for Windows, as operations relative to the local machine and the Uid is simply the Relative ID portion of the SID?

I'd imagine this would only scratch the surface of needs for big NT domain controller Enterprise-y needs.

Would this API be suitable for single hosts, not connected to some big domain controller?

Gid could be documented as a no-op on Windows.  Unix also supports supplemental groups but they're rarely needed.  I figured we could add a method on User to get those later, if actually needed.

HomeDir on Windows could just be Documents & Settings.  We could add methods on User (later) to get various types of directories.  Unix has conventions (and pseudo specs) for certain well-known directories too.

Basically:  is there anything absolutely offensive about this that couldn't be made to work reasonably for smallish Windows configurations?

[Brad Fitzpatrick]

Oh, and to glue two threads together.  The CL is:

http://codereview.appspot.com/4440057/

[brainman]

Just go ahead with whatever ideas you have. Other people will come and bend them along later.

Alex

[Brad Fitzpatrick]

It's always easier to change things early, though.

I'm trying not to be unix-centric with this.  It's obviously not complete for Windows, but I want to make sure it's not fundamentally wrong on Windows.