Ask Your Question
0

Numerical Unix/Linux User account is treated different on setting file permissions by puppet 3.7.3

asked 2015-04-02 13:35:24 -0500

Gans gravatar image

updated 2015-04-02 19:00:43 -0500

GregLarkin gravatar image

Hello All,

We use puppet 3.7.3 community version, and all UNIX user accounts are managed though Centrify on AD.

I wrote a puppet module to create Unix Administrator's SSH key management on Linux machine (since all Unix admins home directories are local to the machine). We do have some Unix user names on numerical.

example :

$ id 109056
uid=9827(109056) gid=1999(sysadmin) groups=1999(sysadmin)

puppet will create /home/109056, .ssh, authorized_keys for all Unix Admins in the organization.

it does it well for all user accounts with alphabets, *no issues here.

but if the UNIX user Id on nuberical, then it treated something else. so we have permission issue.

$ sudo su - 109056
su: warning: cannot change directory to /home/109056: Permission denied
-bash: /home/109056/.bash_profile: Permission denied

the below home directory was created when users login for the first time without puppet involvement (*that works fine)

$ pwd
/home
$ ll
total 32
drwx------ 3 109056  sysadmin 4096 Apr  2 05:24 109056

this one below was created by puppet, the home dir & the user's SSH keys after provisioning ( you can see the number got right aligned, i can see 2 spaces in-front of 109056 "3__109056"

$ pwd
/home
$ ll
total 32
drwx------ 3__109056 sysadmin 4096 Apr  2 05:24 109056

*added underscore above for high-lite "3__109056"

I don't know what is different in the below user change by puppet:

Notice: /Stage[main]/adminkeys/adminkeys::Virtual[109056]/File[/home/109056]/owner: owner changed '109056' to '109056'
Notice: /Stage[main]/adminkeys/adminkeys::Virtual[109056]/File[/home/109056/.ssh]/owner: owner changed '109056' to '109056'
Notice: /Stage[main]/adminkeys/adminkeys::Virtual[109056]/File[/home/109056/.ssh/authorized_keys]/owner: owner changed '109056' to '109056'

Note: have tried single quote / double quote on $admin variable, no difference.

init.pp

class adminkeys {
realize (adminkeys::virtual["109056"])
  @adminkeys::virtual {"109056": admin  =>  "109056", }
}

virtual.pp

define adminkeys::virtual ($admin) {
  file { "/home/${admin}" :
    ensure            =>  directory,
    owner             =>  "$admin",
    group             =>  'sysadmin',
    mode              =>  0700,
  }

  file { "/home/${admin}/.ssh" :
      ensure  => directory,
      owner   => "$admin",
      group   => 'sysadmin',
      mode    => '0700',
  }

  file { "/home/${admin}/.ssh/authorized_keys" :
      ensure  => present,
      owner   => "$admin",
      group   => 'sysadmin',
      mode    => '0600',
      source  => "puppet:///modules/adminkeys/authorized_keys.${admin}",
  }
}

keys are stored under module files folder:

$ ll modules/adminkeys/files/
total 20
-rw-r--r-- 1 root root 1803 Mar 19 15:18 authorized_keys.109056

Thanks for your help!

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2015-04-02 19:08:36 -0500

GregLarkin gravatar image

What flavor of Linux are you using? Very likely, whatever it is does not like usernames to be completely numeric. Since all Puppet does at the lowest level is invoke commands like "useradd", "groupadd", etc. and feed your data to them, it relies on the OS for some of the error checking and validation.

If you try to pass an illegal username to the underlying OS tools, the best case scenario is that Puppet will do some validation for you. If it doesn't, the OS tools themselves should catch illegally-specified data and throw an error.

It may be in your case that the OS tools accepted your data and did not immediately exit with an error. However, an all-numeric username does appear to cause problems with other OS tools.

I would strongly suggest reviewing your username policy and at the very least, add a single alpha character to the beginning of the username to avoid further problems.

edit flag offensive delete link more

Comments

Thanks Greg, It's on RHEL 6.x.

Gans gravatar imageGans ( 2015-04-02 19:27:33 -0500 )edit

According to the GNU useradd man page, "Usernames must start with a lower case letter or an underscore, followed by lower case letters, digits, underscores, or dashes. They can end with a dollar sign. In regular expression terms: [a-z_][a-z0-9_-]*[$]? Usernames may only be up to 32 characters long"

GregLarkin gravatar imageGregLarkin ( 2015-04-02 19:37:44 -0500 )edit

Thanks Greg, I got your point, we are planning to prefix an alphabet sometime in the near future. but it's strange the same numerical account works fine on "chown" command in Linux. this is an issue only thought Puppet file { } type permissions. our Linux user accounts are on AD-Centrify integration

Gans gravatar imageGans ( 2015-04-03 09:07:25 -0500 )edit

Do you have LDAP configured in your puppet.conf file with these settings? https://docs.puppetlabs.com/references/latest/configuration.html#ldapbase I want to make sure I'm looking at the correct user resource provider. It's possible Puppet gets confused and thinks the username is actually the UID.

GregLarkin gravatar imageGregLarkin ( 2015-04-03 10:54:55 -0500 )edit

Here's another test - what happens when you run "chown 9827 /home/109056"? Then what happens when you run "chown 109056 /home/109056"? In your home dir listing above, *uid* 109056 owns /home/109056, not *user* 109056. That's why you get a perm error when you try to su. Puppet may be part of...

GregLarkin gravatar imageGregLarkin ( 2015-04-03 10:57:21 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2015-04-02 11:23:57 -0500

Seen: 405 times

Last updated: Apr 02 '15