markw@hpdmd48.boi.hp.com (Mark Wolfe) (08/28/90)
As a part of beefing up security on the machines I administer, I'm working
on implementing password aging. In order to simplify the process, I wrote a
program that runs at login time and reports the time left before the users
password expires. If there is not an aging field on the entry, I generate one
and append it to the password field.
My question is this:
Is there a proper way to access the passwd file to insure file inegrity and
security? I use the lockf call to reduce the chance of simultaneous access doing
some unknown damage to the file. Is this sufficient, or are there other checks
I should be making to insure multiple accesses leave the file in a good state?
I guess I'm trying to find out if there is some standard (even defacto
standard) method of accessing the password file, or does everyone that does
this invent their own method.
Mark
markw@hpbs1529rickert@mp.cs.niu.edu (Neil Rickert) (08/28/90)
In article <14920004@hpdmd48.boi.hp.com> markw@hpdmd48.boi.hp.com (Mark Wolfe) writes: > > As a part of beefing up security on the machines I administer, I'm working >on implementing password aging. In order to simplify the process, I wrote a > > My question is this: > Is there a proper way to access the passwd file to insure file inegrity and >security? I use the lockf call to reduce the chance of simultaneous access doing Before you worry about locking the passwd file, why don't you work on the more important problems: 1. Making sure the user doesn't just choose the same password again. 2. Ensuring that the user doesn't change to a different password, then immediately change back to the original. 3. Making sure that the user doesn't write down his/her new password, just in case it is forgotten. 4. Making sure that the user doesn't select an easy to guess password, because with all the forced password changes he/she has run out of good ideas for hard to guess passwords. 5. Making sure that the user doesn't login from a PC terminal emulator, with an automatic login script, and with his password there on the PC where anyone with access to the PC can get it. I guess it is hopeless. People will continue to come up with technical solutions to the problem which fail to take into account the real source of security weaknesses - human psychology. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
bernie@DIALix.oz.au (Bernd Felsche) (08/30/90)
In article <14920004@hpdmd48.boi.hp.com> markw@hpdmd48.boi.hp.com (Mark Wolfe) writes: > [intro deleted]> > My question is this: > Is there a proper way to access the passwd file to insure file inegrity and >security? I use the lockf call to reduce the chance of simultaneous access doing >some unknown damage to the file. Is this sufficient, or are there other checks >I should be making to insure multiple accesses leave the file in a good state? Historically speaking, the standard used to be to mkdir /etc/ptmp before editing /etc/passwd, and the do an rmdir /etc/ptmp after writing out mod's. This works for all users because even root can't mknod a special file if it already exists. The other advantage is that the existence of /etc/ptmp can be checked in shell scripts, whereas file locks are more difficult to identify. > > I guess I'm trying to find out if there is some standard (even defacto >standard) method of accessing the password file, or does everyone that does >this invent their own method. > As far as I know, this is the standard method, but I'm not sure too many people know about it. bernie