SVR3 passwd changes mode of passwd file

Stephen Carroll sbc at sp7040.UUCP
Thu Sep 29 00:52:47 AEST 1988


In article <443 at stiatl.UUCP>, meo at stiatl.UUCP (Miles O'Neal) writes:
] In article <5060001 at hpsal2.HP.COM>, morrell at hpsal2.HP.COM (Michael Morrell) writes:
] > I think you're missing the point.  The passwd program should change a user's
] > password and THAT'S ALL.  It has absolutely no business changing anything
] > else (especially if it's not documented!).
] 
] No, I did not miss the point. I was addressing one of the issues that I
] saw in the article; namely that of his user's responses. With as little
] security as unix(tm) has, it's best to be as secure as possible. The other
] issue, that passwd() (or whatever did it) was broke, I did not address.
] In fact, I agree. Its broke.

the passwd program first creates a temp file, ptmp, into which it copies the
contents of the current passwd file, but updating the password for the
user in question.  ptmp is created with umask 0333, or in other words, read 
only access.  after updating the user's passwd, it links passwd to opasswd, 
unlinks passwd, links temp to passwd, and then unlinks ptmp.  now, opasswd
should have the permissions which you may have changed it to, while passwd
has read-only permission.  the reason i am posting this is to throw in my
two cents worth, that passwd does not change the permissions on the passwd
file, but actually creates a new file.  my opinion is that this works
correctly, and for security reasons, is the only way it should work.  if
someone else feels differently, and has no security concerns for their
system, they should hack the source and make things work differently.
if the only complaint is that they hate typing :w! instead of :wq, then
that's just a case of laziness, and should not be posted to the bugs
newsgroup.

this is just my personal opinion of course, and does not include the views
of my company even though they agree with me.

BTW: the reason i am so adamant about this subject is that i am currently
working on a secure unix implementation, where this protection is absolutely
necessary, even though it is a small concern compared to other security
holes.



More information about the Comp.bugs.sys5 mailing list