#2251 policy table processing of long hostname cause errors in xds

2.8
closed
dsh (9)
5
2012-09-19
2011-08-18
Lissa Valletta
No

When a system is installed and the credential generated with a long hostname , for example mn.pok.ibm.com, then the policy table is setup with the
entry mn.pok.ibm.com....trusted. Normally a command is built and the daemon addes in request->{userid} = root for example. In a hierarchical situation, when the command is sent to the service node, if a long hostname is in the policy table, the request->{userid}=mn.pok.ibm.com. This breaks xdsh because it checks the incoming request->{userid} and compares to the current userid. If there is a mismatch it errors out. The workaround is to add the ahort hostname to the policy table for example mn,,,,,trusted and then the problem goes away.
Need to fix this but have not had a chance to debug further.

Discussion

  • Lissa Valletta
    Lissa Valletta
    2012-05-08

    I think the answer would be just to make sure we put long and short hostname in the policy table.

     
  • Lissa Valletta
    Lissa Valletta
    2012-05-08

    I think the answer would be just to make sure we put long and short hostname in the policy table.

     
  • Lissa Valletta
    Lissa Valletta
    2012-06-11

    Just hit this again on Brians machine . Need to fix. The daemon returns the hostname not the userid when this is true and we end up with the xdsh error on the xdsh -K as follows
    Error: When touserid:root is not the same as the current user:c250mgrs33-pvt.ppd.pok.ibm.com. The the command must be run by root id.
    current user should be root not the name of the MN. If you put the long hostname of the MN and not the short in the policy table
    This is because in xdsh.pm we override the DSH_FROM_USERID as follows and in this case $request->{username} is not root but the MN name

    if (($request->{username}) && defined($request->{username}->[0])) {
    $ENV{DSH_FROM_USERID} = $request->{username}->[0];
    }

     
  • Lissa Valletta
    Lissa Valletta
    2012-06-11

    At the very least xcatconfig should always put the long and short hostname in the policy table.

     
  • Lissa Valletta
    Lissa Valletta
    2012-06-20

    So the issue is we call validate with the following input. Note peerhost is always the short hostname. This will not match a long hostname in the policy table.

    Jun 20 10:04:11 rhsn xCAT: call to validate peername = hpcrhmn.cluster.com, peerhost=hpcrhmn username = root

    So in validate these lines fail because peerhost is short and the entry in the policy table is the long name
    if (($rule->{name} and ($rule->{name} eq $peerhost)) && ($rule->{rule}=~ /trusted/i)) {
    $peerstatus="Trusted";
    last;
    }
    and we end up with $peerstatus=untrusted.

    This causes this logic to set the username to the peername

    if (($request->{username}) && defined($request->{username}->[0])) {
    if ($peerstatus ne "Trusted" ) { # then set to peername
    $request->{username}->[0] = $peername;

    The reason it is short because in xcatd before we call service_connection we strip the domain

        if ($domain) {
        # strip off domain if set
        $peerhost && $peerhost =~ s/\.$domain\.*$//;
    } else {
        # otherwise just strip off whatever comes after the first dot
        $peerhost && $peerhost =~ s/\..*//;
    }
    
     
  • Lissa Valletta
    Lissa Valletta
    2012-06-21

    Per dicusson. If originally get a long hostname, validate will check for both long and short hostname.

     
  • Lissa Valletta
    Lissa Valletta
    2012-06-21

    Fixed in 2.8 13140/13141

     
  • Lissa Valletta
    Lissa Valletta
    2012-06-22

    2.7 for 2.7.4 Committed revision 13150