Re: user and group id mappings

Jeff Abrahamson [[email protected]] wrote:
> I'm a bit confused about user and group mappings in sfs.  It looks
> like I need to edit or cause to be modified the /etc/sfs/sfs_users
> file, but it's not entirely clear from the manual / man pages whether
> I should edit this myself or use some program to administer them.  Nor
> precisely how to do these things.  Probably this would be clear if I
> were a sysadmin instead of a programmer and grad student...

Normally, you should not have to edit the sfs_users file manually.  The
most common way that USER entries end up in that file is by running
the "sfskey register" command on the server.  If you're interested in
the format of the sfs_users file, try "man sfs_users".

> The issue is that user 512/512 on the server, member on the server of
> groups 5551 and 5552, is known on the client as 1000/1000 and should
> be members of those groups.
> 
> So the mappings are
> 
>     server	client
>     uid 512	uid 1000
>     gid 512	gid 1000
>     gid 5551	gid 1003
>     gid 5552	gid 1002
> 
> Currently only the first two of these work correctly, 

When you authenticate to an SFS server, your client is mapped (usually
via public key cryptography) to a unix user on the server.  Whatever
UID/GID and set of groups that particular unix-user-on-the-server has,
is what you as the client effectively have when accessing the file
server.

One thing to check is to make sure that the "Userfile" directive in
/etc/sfs/sfsauthd_config has the -passwd flag.  (If you don't have such
a file in /etc/sfs that probably means your using the default which does
include that flag.)

If that flag is there, but things still don't work, you can use SFS's
debugging feature to see what/who the server thinks you are.  On the
client, run "sfscd" (as root) and the "sfsagent" (as yourself).  On the
server, launch "sfssd" as follows: env ASRV_TRACE=10 sfssd -d.  On the
client, "cd" to a directory on the server.  The server will spit out a
bunch of information, but look for the piece like this:

  sfsauthd: ASRV_TRACE: reply sfsauth_prog_2:SFSAUTH2_LOGIN x=a7cc9ff0
  sfsauth2_loginres REPLY = {
    sfs_loginstat status = SFSLOGIN_OK;
    sfsauth2_loginokres resok = {
      sfsauth_cred creds<> = [2] {
        [0] = {
          sfs_credtype type = SFS_UNIXCRED;
          sfs_unixcred unixcred = {
            string username<> = "kaminsky";
            string homedir<> = "/home/kaminsky";
            string shell<> = "/bin/sh";
            u_int32_t uid = 0x1f4;
            u_int32_t gid = 0x1f4;
            u_int32_t groups<> = [5] {
              0x0, 0x1, 0x3, 0x4, 0x5
            };
          };
        ...

If groups<> is empty, that means something probably isn't set up
correctly.  Finally, what version of SFS are you using?  Things have
changed quite a bit with respect to user authentication the 0.7.2
release.  The most recently CVS checkout (as well as 0.7.2) should work,
but it's possible an intermediate checkout (during last Spring/Summer)
might be buggy.

> and even there it's only access permissions that work, ls -lg still
> shows numbers instead of names.

The reason for this is that you're running ls on the client
machine which doesn't know how to map the user and group IDs
(512/5551/5552) that it receives from the server to the correct
user and group names (from the server).  If those IDs existed in
your client's /etc/passwd and /etc/group, you would see the local
(incorrect) values for those user and group names.  Take a look at
http://www.fs.net/sfswww/fileutils.html for more details (I haven't
tried the patch recently, so I'm not sure if it works out-of-the-box
with the current versions of SFS).

Michael