yeidel@tomar.accs.wsu.edu (Joshua Yeidel) (06/26/91)
We have had similar occurances twice: a DS5000 running Ultrix 4.1 suddenly begins refusing logins from any userid except root. On investigation, we find that permissions for a high-level directory (in one case, /, in another, /usr/users) have been changed such that users can't access something vital (in the first case, /bin/csh, in the other, their home directories). Has any one seen anything like this before? Any clues as to the cause (We DO know how to fix it once it's gone wrong, but we'd like to know what might be doing this...) ---------------original message------------------------------- I found the problem ... it was permissions alright ... somehow the permissions on the directory that holds all the userid ids (on the dial machine they are in '/user/users') had gotten changed to rwx------ and the passwd file says the root directory for a user is at /user/users, but they then didn't have the permissions to get to it ... I did three things yesterday which I can identify as the *possible* cause: 1) I copied /bin/lp into /user/users/ftp/bin/ls 2) I generated a new userid, 'ftp' and had the adduser command generate a default $HOME directory for it. Since identifying the problem and fixing it this morning, I have repeated the above steps (i blew it all off yesterday when we started having problems). The problem has not be repeatable. 3) From a userid, 'swanv', I ftped a remote file, uncompressed and untarred it in a directory /user/users/swanv/swb. At no time was I monkeying with the directory '/user/users'. I was monkeying with directories one level down, however. It would be nice to be able to identify the problem, so that it could be avoided in the future, but I am at a loss to currently explain it.
grr@cbmvax.commodore.com (George Robbins) (06/26/91)
In article <1991Jun25.175252.2895@serval.net.wsu.edu> yeidel@tomar.accs.wsu.edu (Joshua Yeidel) writes: > We have had similar occurances twice: a DS5000 running Ultrix 4.1 > suddenly begins refusing logins from any userid except root. > On investigation, we find that permissions for a high-level > directory (in one case, /, in another, /usr/users) have been > changed such that users can't access something vital (in the > first case, /bin/csh, in the other, their home directories). > Has any one seen anything like this before? Any clues as to > the cause (We DO know how to fix it once it's gone wrong, but > we'd like to know what might be doing this...) I mentionted this a while back, but the only way I've seen ultrix gratuitously change ownerships and permissions is when you do a partial restore. In this case, it has been known to modify the permissions of the directory you're restoring into to match the permissions of the parent directory of the file/tree you're trying to restore. I've peeked at adduser, while I don't use it, it looks fairly innocent. Also, I think I saw something in the 4.2 release notes about a bug with chroot being fixed. I don't know the details, but since anonymous ftp is one of the few things that does a chroot, it might be worth investigation. (I'm assuming your were trying to set up an anonymous ftp account). Any DECfolk know the actual details of the chroot thing, or am I off in left field again? -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
dbgwab@edp130edp.arco.com (Bill Bailey) (06/26/91)
I had a similar problem during installation of the Beta test version here. It turned out that when using lprsetup to delete an existing entry ion printcap, the permissions of theuser's home directory can sometimes be changed to not have execute. It happened to me twice. You might want to see if someone was using lprsetup prior to the problem. -- Bill Bailey <dbgwab@arco.com> Voice : (214) 754-6779