Dealing With "Permissions on the password database may be too restrictive" Errors On SUSE Linux 10.x

Hey there,

Here's something I ran into for the first time in my life today (and I don't mean the longest frickin' subject line I've ever written ;)

I was working with a colleague, booting up a recently panicked (I'm assuming, since I wasn't involved when "the incident" happened) SUSE Linux 10 system, when we saw the following error:

Login Failed: Permissions on the password database may be too restrictive.

Or something to that effect. Unfortunately, I don't have the screen to cut-and-paste from (not complaining). We ended up getting this error for regular users and administrative users, including root. It seemed like there wasn't an account available that could log in to the box. Eventually the problem was solved, but it was an interesting situation and, perhaps, some of the following troubleshooting information might be of help to you in the future (So you don't have to boot "rescue" off of CD more than once ;)

Here's how it went down (try to contain your excitement. This is edge-of-your-seat stuff, so, please, go to the bathroom before you continue reading ;)

1. The first thing we did was to try logging in with all the accounts we could think of. None of them worked, although we were relatively sure that they were enabled and had worked previously.

2. Then we did the sanity-check that (interestingly) you don't see too many people do any more: We quit trying to login to the default run level (5 - X-Windows) and tried the same logins we did in step 1 on the machine's local console. At this point, we considered that we may have hit some limit on failed login attempts, but quickly discounted that theory, since our logins had been failing from the start. It's also worth mentioning that this was a newer machine and (as it turned out) had not been attacked in any way that might disable passwords from being accepted.

3. Next, we booted off of CD and ran SUSE Linux in "rescue" mode. This gave us a very easy login. Username: root. No password required. Using "lvscan" we were able to to identify the root partition and ran fsck on all available partitions to ensure that no file system corruption existed.

4. Once all the fsck's came back "OK," we mounted /dev/system/root onto a temporary directory (/tmp/root for instance):

host # mkdir /tmp/root
host # mount /dev/system/root /tmp/root

5. Then we changed directories into what would normally be our /etc directory to look for any obvious signs of damage. None could be found. In fact, it seemed as though the error we were getting was completely erroneous:

host # cd /tmp/root/etc
host # ls -l passwd shadow
-rw-r--r-- 1 root root 25729 Jun 10 05:52 passwd
-r-------- 1 root root 14268 Jun 10 05:51 shadow

Those permissions may seem restrictive, but they're actually required so that users' passwords can remain secure. /etc/passwd should be readable by anyone, but the "passwd" program actually runs "setuid root" so that it can verify the user's password by reading the /etc/shadow file:

-rwsr-xr-x 1 root root 27768 Jul 17 2006 /usr/bin/passwd

6. We added our own user id's to the "wheel" group (root was already a member) and rebooted, to see if that would help, but it didn't. That was lame, I know, but much better than finding out later that it was actually the solution and we never tried it ;)

7. Booting up in rescue mode and mounting the root partition again, we took a look at the /tmp/root/etc/sysconfig/permissions file (We couldn't use Yast's X-Window interface, as explained below). It turns out that the line:

PERMISSION_SECURITY=

was set to paranoid for local security!!!! This was easily fixable by changing it back to the least restrictive of settings (you have easy, secure and paranoid to pick from, I believe):

PERMISSION_SECURITY="easy local"

saved that file and rebooted. All was well :)

The Aftermath:

One interesting thing I noted, when taking a look at the problem afterward, was that "paranoid" local settings were actually set on purpose by another admin (the default for our install image was what we reverted back to - "easy local").

This setting seems like a good idea, because, from the documentation I could find, it purports to make it so that the administrator gets to choose which users can run X sessions and "setuid" programs, although (obviously) it should never be set up and not completely finished and tested before leaving it go ;)

One of the major issues is that, if no one is specifically allowed to run X sessions and/or use setuid programs after this setting is enforced and the machine is rebooted, root is included in the accounts that are denied access to these programs.

The X denial is okay. I can live with that. But not allowing root (and every other account) to use setuid programs makes it impossible for anyone to login. The reason for this is actually pretty simple. When login asks for your password, in simplistic terms, it employs "passwd" (a "setuid" program, as shown above) to read your user entry from /etc/shadow and confirm that your password is actually correct. Since no one is allowed to use "setuid" programs, no one (including root) can login (Via X, remotely or even directly on the local console).

Crazy, but fun for a while ;) Hopefully this helps someone out there :)

Cheers,

, Mike

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Simple Script To List Groups In Passwd File Output On Linux And Unix

Hey There,

Today's simple, but somewhat useful, little Bash Script is brought to you by "The Human Fund: Money For People" ;) That was shamelessly lifted from "Seinfeld," but I always liked that fake name better than UNICEF ;)

Basically, todays Bash script manipulates the output of a simple "cat" of the /etc/passwd file and interpolates primary and secondary group values, for each user, into their respective output lines. It should run equally well on virtually any Linux or Unix distro since the passwd fields are in the same order on almost all of them and it doesn't make use of any of the group file fields past the fourth (so extended group files shouldn't affect this).

NOTE: This script goes well with this bash one liner to generate somewhat fancy w output. Haven't had your fill of pap for the day? Check that out ;)

The output you'll get from the script is similar to a simple "cat" of the /etc/password file (senility awareness kicking in - I just mentioned that ;), except that the fourth field will be modified. When you run this script, you'll notice that the fourth field of colon-delimited output includes alpha dash (-) delimited output of the form: pg=XXXX-sg=XXXX, rather than just the standard numeric Primary Group ID. The "pg" stands for Primary Group and the "sg" stands for Secondary Group. The Secondary Group, it should be noted, may contain more than one entry (split by commas), if the user belongs to more than one secondary group, and will print "NONE" if the user ID being listed doesn't belong to any groups other than its primary.

The script's simple to to run (because it doesn't have any fancy options ;) and should work fairly quickly (although, like everything, it could probably be more efficient. Once I fully develop my insect-like ability to differentiate microseconds, this sort of thing will bother me much more ;).

To run it, simply run it, like so, and you'll get your output (This is from a stripped Solaris box with only one user account and several useless standard accounts removed):

host # ./pwgroups
root:x:0:pg=root-sg=root,other,bin,sys,adm,uucp,mail,tty,lp,nuucp,daemon:Super-User:/:/sbin/sh
daemon:x:1:pg=other-sg=bin,adm,daemon::/:
bin:x:2:pg=bin-sg=bin,sys::/usr/bin:
sys:x:3:pg=sys-sg=sys::/:
adm:x:4:pg=adm-sg=sys,adm,tty,lp:Admin:/var/adm:
lp:x:71:pg=lp-sg=lp:Line Printer Admin:/usr/spool/lp:
uucp:x:5:pg=uucp-sg=uucp:uucp Admin:/usr/lib/uucp:
nuucp:x:9:pg=nuucp-sg=nuucp:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico
smmsp:x:25:pg=smmsp-sg=smmsp:SendMail Message Submission Program:/:
listen:x:37:pg=adm-sg=NONE:Network Admin:/usr/net/nls:
webservd:x:80:pg=webservd-sg=webservd:WebServer Reserved UID:/:
postgres:x:90:pg=postgres-sg=postgres:PostgreSQL Reserved UID:/:/usr/bin/pfksh
nobody:x:60001:pg=nobody-sg=nobody:NFS Anonymous Access User:/:
noaccess:x:60002:pg=noaccess-sg=noaccess:No Access User:/:
nobody4:x:65534:pg=nogroup-sg=NONE:SunOS 4.x NFS Anonymous Access User:/:
user1:x:37527:pg=unixteam-sg=guys,folks:Captain Beefmeat:/export/home/user1:/bin/bash

Sure, this script won't save lives (or even change any ;) but I have found use for it from time to time. ...Which stands to reason, I suppose. If I don't think I'm ever going to do something again, I almost never script it out ;)

Hope you find it useful or, at least, mildly amusing :)

Cheers,





This work is licensed under a
Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License

#!/bin/bash

#
# pwgroups - add alpha primary and secondary group information to /etc/passwd output
#
# 2009 - Mike Golvach - eggi@comcast.net
#
# Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License
#

export IFS=":"
while read one two three four five six seven
do
        pri=$(grep -w ${four} /etc/group|awk -F":" '{print $1}')
        sec=$(echo `grep -w ${one} /etc/group|awk -F":" '{print $1}'`|xargs echo|sed 's/ /,/g')
        if [[ ${#sec} -eq 0 ]]
        then
                sec=NONE
        fi
        echo "${one}:${two}:${three}:pg=${pri}-sg=${sec}:${five}:${six}:${seven}"
done </etc/passwd

, Mike

---

Discover the Free Ebook that shows you how to make 100% commissions on ClickBank!

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Another Simple Scriptlet To Make The Unix And Linux CLI More User Friendly

Hey there,

Today we're going to shoot out another quick scriptlet that might be useful (or distracting ;) from time to time. It’s a bit of a follow up on our post from earlier this week on using bash to produce fancy user names for folks logged into your machine, although it’s a little bit longer. Once again, if you go by the 65 character rule, this isn’t a one liner, even though it’s all going on one line ;)

Our little foray into variable interpolation today has to do with making /etc/passwd just a bit more accessible. Most folks are familiar with the 7 colon-separated fields of this file (if not, they’re: The user’s Username, an encrypted password (or usually an “x” if you’re using a shadow password system), the user’s UID, the user’s GID, the user’s gecos information (Also referred to as the “comment field,” usually either empty or populated with a short description to make the account more easily recognizable) , the user’s home directory and, finally, the user’s default shell)

Now, say what you will about the structure and setup of the passwd file, but it’s fairly easy to follow. Almost everything in it is the opposite of cryptic. The password field (field number 2) is, of course, not going to be tailored for your ease of understanding ;) If you get really lucky and you hop on a machine that actually lists the encrypted password in field two of /etc/passwd, you can copy the file to any remote machine and go to work on it. We've posted quite a few scripts to do automated password cracking. You should just see an "x" for a standard user account. If you don’t, have a talk with your SysAdmin or, if you’re him, please move on to a shadowed password system. Too much information exists in the public domain to make the old-style setup anything more than a trifling hassle to someone who wants to exploit your system. Especially a disgruntled employee!

Other than that, the user ID (field number 3) is an easy relation to make, since the username is in the same file (field number 1). The only thing in there that doesn’t practically explain itself is field number 4; the GID (group id) field. It’s not that big of a deal to look a user up in /etc/passwd, glean that group id information and find out what group the user is in by looking at /etc/group. It’s as simple as this:

host # grep user1 /etc/passwd
user1:x:37527:501::/export/home/user1:/bin/bash
host # grep 501 /etc/group
people::501:

and, just like that, we know that the user "user1"'s primary group membership is in the group "people." There are also secondary groups to consider, but finding this out is trivial as well. Just do the following:

host # grep -w user1 /etc/group
guys::600:user1
folks::601:user1

And, yes, I can hear you out there ;) I'm aware of commands like "groups" and "id" ;) They're very good at getting this information, as well (which is why we're going to use "groups" in our one-long-liner. Your output may look slightly different). Note that some versions don't have the -a option for "id" and some have either -g, -G, any combination of the three or all of them - it depends on your distro:

host # groups <-- This is supposed to list groups in order, from left to right, with the leftmost group being the "primary" and every group after that being a "secondary." The ordering of the "secondary" groups in the list is generally "as they appear" in /etc/group. So, since the line with "guys" is on a line closer to the beginning of the /etc/group file than the line with "folks," they're printed in that order. No other relationship exists between them that I'm aware of.
people guys folks
host # id -a
uid=37527(user1) gid=501(people) groups=501(people) <-- On Solaris; not quite as helpful as "id" on other flavours of Linux or Unix.

Anyway, I think I've met my word-count quota ;) Just kidding. I have no idea how much I've typed. I'm not even sure I want to know...

Here's a nice little command line (and, consequently, the topic of this post ;) to print every user's group(s) in the (modified) output of /etc/passwd. Just type it out, like so:

host # IFSBAK=$IFS;export IFS=":";while read one two three four five;do groupnames=`groups $one|sed 's/ /,/g'`;echo "${one}:${two}:${three}:${groupnames}:${five}";done </etc/passwd;export IFS=$IFSBAK


...lots of output left out for reasons of brevity and security :) ...
noaccess:x:60002:noaccess:No Access User:/
user1:x:37527:people,guys,folks::/export/home/user1:/bin/bash
...

And, there we have it. All nice and tidy :) Here's the same thing in script format (below) to make it a little easier to read. Be sure (now matter how you run it) that you don't clip the beginning and end, as you'll probably want to reset your shell's IFS (field separator) to what it was before we changed it to the colon (:) to make parsing /etc/password possible without using awk or cut, etc... Also, if it's of any interest and you noted that I only counted my variables up to "five" it's because "while read" will swallow up the rest of a line in its last variable. So, instead of reading and writing five, six and seven, I just read five, since that would include from field five all the way to the end of the line (at the end of field 7), and field 4 (the group field) was the last field on every line that we were actually interested in :)

#!/bin/bash

IFSBAK=$IFS
export IFS=":"

while read one two three four five
do
 groupnames=`groups $one|sed 's/ /,/g'`
 echo "${one}:${two}:${three}:${groupnames}:${five}"
done </etc/passwd

export IFS=$IFSBAK

Have a great weekend!

, Mike

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Bash One-Liner Script To Produce Somewhat-Fancy Output Of Who's On Your Linux Or Unix Box

Hey there,

Today we're going to shoot out a quick one liner script that can come in handy from time to time. It doesn't fall under the "necessary" category (or, maybe not even the "useful" one ;), but it's nice to have for those times when you just don't feel like doing any extra typing or expending the effort required to separate the wheat from the chaff on a screen full of garbage output. That is, as I've always understood, one of the main reasons to script things out in the first place. The other reasons, like automation, efficiency, etc, are pretty much ignored here, even though we will be automating a repetitive action and that, by definition, will make our waste of company time more efficient. No matter how you look at them, automation and efficiency always seem to be a good thing ;)

This "script" is really just a simple pipe-slam so that we can figure out who's on the machine with us (my preference is for a script, but - as you'll soon see - this could just as easily be an alias, etc). Sure, we could just type "w" or "who," (and "w" does form the base of this bash one-liner script), but we'd like to have this whole thing look more personal. And by personal, I mean, we'd like to know who else is on other than us by UID or login name. The functionality (or relative merit) of this script depends heavily on the way in which users were created on your machine in the first place. If no "comment" (or "gecos") field is populated for users on your system, this command-chain is completely worthless.

For instance, assuming we had a user, with a login name of user1, logged in at the same time as us, with an entry that looked like this in /etc/passwd:

user2:x:32678:99::/home/user2:/bin/bash

and our /etc/passwd entry looked like this:

user1:x:32677:99:Mike The SysAdmin:/home/user1:/bin/bash

the command would pull no useful information for user2. So, if the output from w looked like this:

host # w
 13:49:12 up 8 days,  3:41,  2 users,  load average: 0.00, 0.14, 0.43
USER     TTY        LOGIN@   IDLE   JCPU   PCPU WHAT
user2    pts/0     08:44    5:03m  0.01s  0.01s -bash
user1  pts/1     09:05    0.00s  0.04s  0.00s w

our command would only produce output like this:

host # ./wdo.sh
Mike The SysAdmin

Whereas, if we added a comment field (perhaps via usermod -c "Bob The Guy Who Used To Be Anonymous" user2 or the chfn command), we would get nice output like the following:

host # ./wdo.sh
Mike The SysAdmin
Bob The Guy Who Used To Be Anonymous

and so forth, with users who had multiple sessions open being reported more than once. This script was written to give us a warm, fuzzy feeling, so seeing Bob's name five times is no big deal. If you want to use it for profiling purposes on a more heavily trafficed machine, there's always "sort."

Note, of course, that your version of Unix or Linux may produce slightly different output for the "w" command and xargs' -i flag may be "-I" (also, if, for some bizarre reason, your login names have spaces in them, just be sure to double quote the variable you define via xargs with the -i or -I flag. This should never happen). Basically, what I'm saying is, this script probably won't run correctly, exactly as it comes, on every single distribution of Linux and Unix out there :)

Enjoy the neighborhood watch :)

Cheers,

#!/bin/bash

#
# wdo.sh - More comments than code :)
#

w|awk '{print $1}' |xargs -ibing grep bing /etc/passwd|awk -F":" '{print $5}'

, Mike

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Using Grub To Change RedHat Linux's Root Password

Hey There,

I'm back from the dead and no longer cursing Vista ( I've always thought it was strange that most people, including myself, feel disappointment or sorrow when they lose something they didn't have in the first place. The opposite seems perfectly logical. I feel very relieved that I no longer have something that I never had before ;)

Today, we're going to take a look at a quick way to get back your root password (assuming its yours) if, for some reason, you get locked out of your machine. It happens... more than I'd care to admit ;) The course of action I see followed most often is booting from CD, temporarily mounting the physical root drive, and editing /etc/passwd. This is a time-tested solution, and works on pretty much any version of Linux or Unix I've worked with, but I think this way is more fun (and slightly less dangerous). Plus, it saves you a little time (not a lot; just a little). We haven't taken a look at grub since our post on recovering failed raid disks, so I guess this post is about due.

The trick in question has only been tested on RedHat Linux ES, so I can't speak for whether it works on, say, CentOS or Fedora (although I imagine it would work on any system that uses grub for boot loading). Basically, what we're going to do is use grub's boot options to allow us to obtain root access. And, if your machine is properly secured (the /boot directory in particular), you shouldn't be able to edit /etc/grub.conf as a normal user, so physical access (or console/ALOM-type access) to the machine in question is required. It's a pretty simple procedure and goes something like the following:

1. Login to the console on the machine and type "reboot" or "shutdown -r," etc, if you have an account with privileges to initiate such an action. If you don't have an account with suitable privilege, try control-alt-delete (and power off) or hard power-down your machine (you may need to fsck later, but that's a given), take a deep breath and count to 11 ;)

2. Power on the server and wait for the grub boot screen to come up. You'll may not need the GUI for this to work, but it's the only way I've done it. When the grub boot menu comes up, hit the up or down arrow key at least once to stop the automatic boot countdown timer. If you have multiple boot options, choose the one you know (or believe) is the one currently in use (actually, this shouldn't matter, but loading up an older kernel might cause issues) and press the "e" key to enter edit mode.

3. After you enter edit mode, you'll be presented with a few lines of text (dependent on how you have your grub.conf populated). Using your arrow key again, navigate to the line that starts with "kernel." Press the "e" key again, and your cursor should show up at the end of the "kernel" line (if it doesn't, you can move it to where you need it by using the left and/or right arrow keys as necessary).

4. Now that you're in edit mode, and your cursor is in the correct position, type a "space" character followed by "single." So if your boot command line was:

kernel /boot/vmlinuz-2.6.9-34.ELsmp ro root=/dev/sda1
it would now be:
kernel /boot/vmlinuz-2.6.9-34.ELsmp ro root=/dev/sda1 single

5. Now type "b" to continue the boot process and you'll be dumped into a limited shell, as root, passwordlessly. Sometimes this has seemed not to work for me if I changed my edit-focus to a line other than the "kernel" line before typing "b", but that could just be superstition on my part. Thankfully, I don't have to do this all that often :)

6. The rest is gravy. You're root, so all you have to do is type "passwd", set the root password to whatever you like and reboot using your preferred method (reboot, shutdown -r, init 6, whatever works, etc). Since you're in a single-user shell, you can also instantiate a reboot by just typing "exit."
And you should be all set. Now you no longer have an excuse to avoid fixing problems on that machine (the downside ;)
Cheers,

, Mike

---

08/06/2008 - Thanks for this Additional Useful Information From zcat:

On many distros the 'single' or 'rescue' boot will still ask for a
password. You can get around this by starting linux without starting
initd, just launch a shell instead; and it's blindingly fast.

'e' to edit the boot entry, select the kernel line and press 'e'
again, then type "init=/bin/bash", enter, press 'b' to boot it. You
end up at a root prompt with / mounted read-only. (depending on the
distro, you might need /bin/sh instead)

# mount / -o remount,rw
# passwd
<change your root password here>
# mount / -o remount,ro
<three-finger salute or hit the reset button>


It's also useful for fixing up boot problems, if you're silly enough
to have put commands in various init scripts that don't actually exit
or daemonize...

---

Thanks for these comments from Laurent regarding an alternate way to get to single user:

Nice to see that method that I was used to apply. Especially with some servers that have been hardened with password aging implementation. And when it is stable you don't need to log on for more than 60 days sometimes....

You could also add that grub can (should?) be password protected.

Cheers

Laurent

Security Basics For Linux and Unix Installations - Part 2

Hey there,

Following up on our first two posts on basic Linux and Unix installation security and even more installation security measures, we're going to move on to the next section. Today, we'll be focusing more specifically on user, and group, accounts, and modifications that we want to make in that arena.

Again, this series of posts is based mostly on Solaris Unix and RedHat Linux, so it can't possibly apply to everything. I welcome any comments regarding it, especially as they pertain to additional security and other Operating Systems. Just to be clear, also, we won't be touching on more advanced stuff like setting up firewalls, etc. The summary of this 5-part post should end up being a bullet list that you can run through and take care of without having to go too crazy ;)

And, of course, my suggestion, to everyone who has the rights and means, is to script out as much of this method as possible. However you end up securifying your system, once you have your routine down, having Jumpstart or Kickstart do it for you from then on out is much less of a hassle (usually :)

See you tomorrow for section 3!

Cheers,

OS Installation Guidelines, Part 2: Users and Accounts

1. Add accounts for all necessary users. Require valid reasons for all accounts created.

2. You can ignore this step if you're using Solaris or RedHat's OpenSSH pkg or rpm, since it will be complete already: Be sure to add a user account for sshd. This will be required for our OpenSSH to run correctly. Should be as simple as

host # useradd –m –d /users/sshd sshd
host # passwd –l sshd <--- (The passwd –l just locks the password so no one can login to the account. This is okay, since the sshd account is only necessary for privilege separation.

IMPORTANT NOTE FOR POINTS 3 THROUGH 6 REGARDING USER REMOVAL: Please note that for point three, we specify "userdel -r," because these users have home directories that are NOT "/" - If there is any doubt in your mind that an account you want to remove has the root filesystem as its home directory, use "userdel" without the -r, as use of that flag may effectively destroy your system. An easy way to find out what a user's home directory is involves simply grepping the username out of /etc/passwd and checking out the second to last field.

3. userdel –r lp, uucp, nuucp, some, all or more if possible (the nobody account should be removed, too, unless it’s used by a web server or some other application). Note that your list will be larger on RedHat since they generally have a user for every service and you should remove every user for every service you're not using if it wasn't removed by rpm -e. Also, on Redhat, be sure to check for matching entries for the user in /etc/group

4. userdel nobody (This should not be removed if it’s used by a web server or some other application)

5. userdel smtp (Non-existent in Solaris9).

6. userdel mail (Non-existent in Solaris9).

7. chmod 700 all user directories.

8. Comment out gsscred and nfsfind from root cron on Solaris. Delete sys, lp, adm, root.au, uucp and all unnecessary crontabs, if possible.

9. Add “0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/lib/sa/sa1” and “59 23 * * * /usr/lib/sa/sa2 -b -g -r –u” to root's cron. On RedHat you'll need to have the sysstat RPM installed in order to use sar. If it "is" installed on Redhat, check out /etc/cron.d to make sure that it is being run in cron and modify the setup per above, to increase or decrease the number of times it runs, if you need to.

10. Create the directory /var/adm/sa (/var/log/sa on RedHat) if it doesn't exist, and chown it to root:yourAdministratorsGroup. Then chmod the directory to 660.

11. Add “/usr/lib/acct/ckpacct” to root's cron on Solaris, if the machine does not have high user activity and has adequate disk space for logging. Remove any other /usr/lib/acct lines in the Solaris root crontab. For RedHat users, make sure that you have the psacct RPM installed. The default settings should be okay and you can use chkconfig or ntsysv to ensure that process accounting is set to run at boot time.

12. Remove user directories for users who no longer have accounts on the machine.

13. Remove crontab entries in /usr/spool/cron/crontabs (Solaris) or /var/spool/cron (RedHat) for users that no longer have accounts on the machine.

14. Add empty .rhosts, .netrc and .exrc files in all user home directories.

15. chmod 0 and chown root all user .rhosts, .netrc and .exrc files.

16. userdel (–r, if their home directory isn’t "/" ) all users, aside from root, with uid 0.

17. Change the group for any user (other than root) that has a gid of 0, if possible.

18. Be sure to include a umask of 022 in any user’s .profile if their account will require their home directory to be somewhat publicly available. Examples of such an accounts include development or group-based accounts. These kind of accounts are used to ease the ability of a group to work together. Of course, the standard 027 umask would make this impossible. Please use discretion and do this only for accounts where the need is real.

19. For all generic accounts, make them su-only. You can find detailed instructions on how to do this, including some pitfalls and stumbling blocks you may encounter, in our post on making generic accounts su only. As luck would have it, it's still aptly named ;)

to be continued...

, Mike

Setting Locked, No-Login and Login Accounts On Solaris 10

Hello again,

Today we're going to look at a feature of Solaris' passwd command that has been around since Solaris 9 ( If you read this and you like the functionality, but are still using Solaris 8, check out this page regarding Sun Bug ID 6227256, which basically states that this functionality will never be back-ported to Solaris 8. I always thought it was strange that they considered this a Solaris 8 "bug" since the extra passwd functionality wasn't introduced until Solaris 9. I would have filed it under "feature-set enhancement," like the /dev/random patch, but I guess that's neither here nor there.

In any event, our post today is going to cover the difference between using the passwd command to lock user accounts, make them no-login (which can also be done if you set the user shell to a "nologin" shell) and, ultimately, reverse the process if necessary. Of course, all of this can be done manually if you like to edit the /etc/shadow file by hand. I'd advise against it. It has the potential to turn out very badly ;) This "added" functionality can also be used to make our script to remove old users network wide (and its Linux counterpart) a little more flexible. Sometimes it's good to have options other than just "locking" an account (or manually setting NP) if you need to keep an account around, but don't want the user logging in anymore.

Generally, if you look in a standard Solaris box's /etc/shadow file, in the password column, you'll either see a regular password entry (encrypted), like "557LIW.RqHi92," a locked password entry, like "*LK*" or a "No Password" password entry, like: NP (The fair equivalent of a no-login password on Solaris 9 and 10).

You can always check what kind of password you have by running:

host # passwd -s
user1 PS

This shows that our logged in account "user1" has a password set (PS). You can look at all users' password settings by running "passwd -sa," but you need to be root to do so. LK will stand for "locked" and "NL" means "no-login."

Now, moving along, there may be plenty of reasons you need to have an account locked and not removed from your system (That's your business. I'll stay out of it ;) The one thing to remember about a "locked" account (*LK* in /etc/shadow) is that it is truly barred from any activity. Not only can the account not login to the machine, it also can't make use of other services like cron, etc. A user account that has "no password" (NP in /etc/shadow) can't login to the machine either, but "can" use system facilities like cron. Changing a user account from "locked" to "no password" can be tremendously advantageous if you can't let the user log in any more, but still need to keep the account around to run nightly jobs, or what have you.

So, let's say we have a user (his login will be "badseed1") that we needed to restrict access to on our Solaris Box. Let's also say that we did it when the box was running Solaris 8, and we did the simplest thing possible and locked up his account by running:

host # passwd -l badseed1

So, now that we've upgraded to Solaris 9 (or 10), we get the following when we check on his account (let's say it turns out we really need his account to be performing some action that it hasn't been performing since we stopped letting him log in. We didn't notice for a really long time. We were busy!!! ;)

host # passwd -s badseed1
badseeed1 LK

And we have confirmation that his password is locked. This is good (in that it makes sense) because we know that "locked" accounts can't use cron. The first thing we're going to do is get his shadow entry up to speed. That is, we're going to leave his account locked, but change the way Solaris handles his entry. In Solaris 8, his password entry in /etc/shadow simply consisted of "*LK*", but we're going to change that to make it like everyone else's (This also makes our previous post on generating encrypted password strings somewhat obsolete, but still entertaining :). It will only take two passwd commands to do this and then we can see the difference:

host # grep badseed1 /etc/shadow
badseed1:*LK*:::::::
host # passwd badseed1
New Password:
Re-enter new Password:
passwd: password successfully changed for badseed1
host # grep badseed1 /etc/shadow
badseed1:Xe0.pVr4gvvh6:::::::
host # passwd -l badseed1
host # grep badseed1 /etc/shadow
badseed1:*LK*Xe0.pVr4gvvh6:::::::

Now, as you see, the user account is still locked but, instead of having just "*LK*" as his or her shadow password entry, the locked password is now simply the regular password with the "*LK*" string prepended to it. This allows us to do the following if we want to "unlock" the password and restore the user to the password they originally had without having to do anything extra!

host # passwd -u badseed1
host # grep badseed1 /etc/shadow
badseed1:Xe0.pVr4gvvh6:::::::

Now, we just have one last thing to do before we can get on with our lives. We need to set up badseed1's account so that it's "no-login." We want badseed1's account to be able to run cron jobs, but we don't want the user to be able to login, so providing the "no-login" shell is a happy medium between the two extremes of absolute availability and complete lockdown. And, again, this can now be done with a single command:

host # passwd -N badseed1
host # grep badseed1 /etc/shadow
badseed1:NP::::::

And we're all set. badseed1 can no longer log into our systems, but his or her cron jobs will run!

Hopefully you'll find some good use for these two very helpful new options to passwd ("-u" and "-N"), as well as the newer locking system used by the standard option "-l" ...ok, the options, as of the time of this writing, aren't technically "new," but they were at one point, and, hopefully, if they aren't new to you, this post has served as an enjoyable refresher :)

Best wishes,

, Mike

linux unix internet technology