[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::digital_unix

Title:DIGITAL UNIX(FORMERLY KNOWN AS DEC OSF/1)
Notice:Welcome to the Digital UNIX Conference
Moderator:SMURF::DENHAM
Created:Thu Mar 16 1995
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:10068
Total number of notes:35879

9883.0. "login: no shell: Permission denied" by JRDV04::SURUGA () Tue May 20 1997 04:24

Two users in my workstation cannot login and the system shows
following message.  One user does not have this problem.  This 
machine (techjj) is a NFS and NIS server and having this problem, 
but the users can login to the client system without any problem.  

Can someone tell me what cause the permission denied ? 

Thanks,

K. Suruga



Digital UNIX (techjj.osa.dec.com) (ttyp2)

login: xxxx
Password:
Last login: Tue May 20 14:03:34 from jaja.osa.dec.com

login: no shell: Permission denied.
Connection closed by foreign host.
T.RTitleUserPersonal
Name
DateLines
9883.1A little more info...RHETT::PARKERTue May 20 1997 10:0215
    
    Hi, K. 
    
    First get their passwd file entry using "grep username /etc/passwd"
    or "ypcat passwd | grep username"
    
    Then make sure their shell is there using "ls -l" and check
    the permissions also. 
    
    If that does not help, post what you found here. 
    
    Hth,
    
    Lee
    
9883.2/etc/passwd & NIS passwd conflictSIOG::BR_MURPHYTue May 20 1997 11:1510
    
    I suspect that as the NIS Server the two users who can't login have set
    their NIS passwd using yppasswd, but still have entries in
    techjj:/etc/passwd file (with a different password). Local admin file
    entries generally take precedence over NIS admin file entries.
    
    Depending on your requirements, it's probabley easiest just to remove
    these users entries from the local /etc/passwd file & rely solely on
    NIS.
    
9883.3JRDV04::SURUGAWed May 21 1997 03:0330
Thanks for replies, but no go yet. 

>    First get their passwd file entry using "grep username /etc/passwd"
>    or "ypcat passwd | grep username"
>    Then make sure their shell is there using "ls -l" and check
>    the permissions also. 
I don't see any problems here. 

>    I suspect that as the NIS Server the two users who can't login have set
>    their NIS passwd using yppasswd, but still have entries in
>    techjj:/etc/passwd file (with a different password). Local admin file
>    entries generally take precedence over NIS admin file entries.

I have removed symbolic link, /var/yp/src/passwd -> /etc/passwd then copied 
the /etc/passwd file to /var/yp/src and did 'make passwd'.  Also reboot 
the server, but the error message is still the same.  I also created a new 
user called foo and pointed home directory to /usr/tmp but did not copy 
any .login or .cshrc. The error message is same.  One interesting thing is 
that the NIS client does not have this problem.  I can login as foo or other 
2 users does not have the problem.  

Oh, I am using 

Digital UNIX V3.2D-1 (Rev. 41); Wed Mar  6 12:39:19 JST 1996
Digital UNIX V3.2D-1 Worksystem Software (Rev. 41)
Digital UNIX Japanese Support V3.2C (rev. 8)

Thanks,

K. Suruga
9883.4Recreate NIS MasterSIOG::BR_MURPHYWed May 21 1997 05:4530
    > I have removed symbolic link, /var/yp/src/passwd -> /etc/passwd then
    > copied the /etc/passwd file to /var/yp/src and did 'make passwd'.  Also
    
    Remember, it's generally considered good practise to remove all
    references to sys admin id's from /var/yp/src/passwd. ie root,bin,lp
    etc.
    
    > I also created a new user called foo and pointed home directory to
    > /usr/tmp but did not copy any .login or .cshrc. The error message is
    > same.  One interesting thing is that the NIS client does not have this
    > problem.  I can login as foo or other 2 users does not have the
    > problem.
    
    How did you create these users? By directly editing /etc/passwd? If so
    then try running mkpasswd. Alternatively, make sure there are no
    entries for these NIS users in techjj:/etc/passwd & the last line is +:
    Then run mkpasswd. When adding new NIS users. The only files that
    should need modifying are /var/yp/src files. These can be editted
    directly & a var/yp/make executed.
    
    Another alternative, is to recreate the NIS Server.
    	o stop NIS /sbin/init.d/nis stop
    	o Remove all NIS entries from /etc/rc.config
    	o delete /var/yp/<NIS domainname> directory & contents
    	o delete /var/yp/binding/<NIS domainname>.*
    	o Make sure /var/yp/src files are upto date 
    	o Run nissetup command & create NIS MASTER Server for
    	  <NIS domainname>
    
    Brendan
9883.5JRDV04::SURUGAWed May 21 1997 23:2126
>    How did you create these users? By directly editing /etc/passwd? If so
>    then try running mkpasswd. Alternatively, make sure there are no
>    entries for these NIS users in techjj:/etc/passwd & the last line is +:
>    Then run mkpasswd. When adding new NIS users. The only files that
>    should need modifying are /var/yp/src files. These can be editted
>    directly & a var/yp/make executed.

I usually modify /var/yp/src/passwd file then execute
'make passwd' to add new users.  

>    Another alternative, is to recreate the NIS Server.
 
I tried to delete/add the NIS server setup as you suggested but 
did not help.  

One thing I discovered is that if I add user, foo, in /var/yp/src/group as
follow, this user can login, but when I remove, I get same error message -
'login: no shell: Permission denied'. 

	system:*:0:root,foo

What is the suggested entries for /etc/group and /var/yp/src/group files ?

Thanks,

K. Suruga
9883.6NIS detailsSIOG::BR_MURPHYThu May 22 1997 06:1111
    Unless you want a user to be able to switch user to root, then you
    should never add them to the system group.
    
    What version of Digital Unix are you running?
    
    Could you post a copy of /etc/rc.config & /var/yp/src/passwd & group.
    
    Verify the link /bin -> usr/bin exists. If not create it with 
    cd /; ln -s usr/bin bin
    
                                               
9883.7finder.uvo.dec.com::COFFEYJLa Feline Flooz - a unix catThu May 22 1997 09:1623
>    Unless you want a user to be able to switch user to root, then you
>    should never add them to the system group.


They still need the password though don't they. 

Doesn't this sound like the permissions somewhere in the basics
of logging in have gone if being in group system allows it to 
suceed?

Something like the shells themselves or /etc/shells having 
been changed to rwxr----- root system instead of something 
more generous like maybe rwxr-xr-x ???


Would a setld -v on the base operating system help? 
Does the IVP for OSFBASE actually check the permissions 
and ownership of the files, there must be something that 
does... 

Has there by any chance be a restore from backup of
a part of the system recently - if so is there any 
chance it was restored with different permissions?
9883.8JRDV04::SURUGAFri May 23 1997 03:04269
RE: -1, -2

How about Inspect.  I installed V2.4 months ago.  Does it cause such 
problem after been installed for weeks ???

>    Unless you want a user to be able to switch user to root, then you
>    should never add them to the system group.

Yes, that's why this would not be the workaround...:<
    
>    What version of Digital Unix are you running?

See 9883.3
    
>    Could you post a copy of /etc/rc.config & /var/yp/src/passwd & group.

Attached below
    
>    Verify the link /bin -> usr/bin exists. If not create it with 
>    cd /; ln -s usr/bin bin

root@techjj# ls -lg /b*
lrwxr-xr-x   1 root     system         7 Mar  1  1995 /bin -> usr/bin
root@techjj#

>Doesn't this sound like the permissions somewhere in the basics
>of logging in have gone if being in group system allows it to 
>suceed?

I believe so too, but where else can I check ???

>Something like the shells themselves or /etc/shells having 
>been changed to rwxr----- root system instead of something 
>more generous like maybe rwxr-xr-x ???

Yes, I already checked this...

root@techjj# ls -lg /etc/shells
-rwxr-xr-x   1 bin      bin           64 Jul 25  1995 /etc/shells

Also other shell files.

root@techjj# ls -lg /bin/*sh
-rwxr-xr-x   2 bin      bin       131072 Jul 25  1995 /bin/Rsh
-rws--x--x   3 root     bin        16384 Jul 25  1995 /bin/chsh
-rwxr-xr-x   1 bin      bin       237568 Jul 25  1995 /bin/csh
-rwxr-xr-x   1 bin      bin       278528 Jul 25  1995 /bin/ksh
-rws--x--x   1 root     bin        24576 Jul 25  1995 /bin/rsh
-rwxr-xr-x   2 bin      bin       131072 Jul 25  1995 /bin/sh

>Would a setld -v on the base operating system help? 
>Does the IVP for OSFBASE actually check the permissions 
>and ownership of the files, there must be something that 
>does... 

Tried following, but no help.  

root@techjj# setld -v OSFBASE350

Base System  (OSFBASE350)
root@techjj# setld -v OSFBASE360

Base System - Patch 001  (OSFBASE360)


>Has there by any chance be a restore from backup of
>a part of the system recently - if so is there any 
>chance it was restored with different permissions?

No, the system was never restored since day 1. 


/etc/rc.cofig

#!/bin/sh
# 
# *****************************************************************
# *                                                               *
# *    Copyright (c) Digital Equipment Corporation, 1991, 1995    *
# *                                                               *
# *   All Rights Reserved.  Unpublished rights  reserved  under   *
# *   the copyright laws of the United States.                    *
# *                                                               *
# *   The software contained on this media  is  proprietary  to   *
# *   and  embodies  the  confidential  technology  of  Digital   *
# *   Equipment Corporation.  Possession, use,  duplication  or   *
# *   dissemination of the software and media is authorized only  *
# *   pursuant to a valid written license from Digital Equipment  *
# *   Corporation.                                                *
# *                                                               *
# *   RESTRICTED RIGHTS LEGEND   Use, duplication, or disclosure  *
# *   by the U.S. Government is subject to restrictions  as  set  *
# *   forth in Subparagraph (c)(1)(ii)  of  DFARS  252.227-7013,  *
# *   or  in  FAR 52.227-19, as applicable.                       *
# *                                                               *
# *****************************************************************
# 
# HISTORY
# 
# @(#)$RCSfile: rc.config,v $ $Revision: 4.2.3.8 $ (DEC) $Date: 1992/11/24 16:41:43 $
# 
# The variables set by the netsetup program that are required for network
# configuration are as follows:
#
# HOSTNAME - host name of the system
#
# NUM_NETCONFIG - number of network devices currently configured
#
# MAX_NETDEVS - maximum number of network devices that can be configured
#		which is currently set by netsetup to a value of 16
#
# NETDEV_n - network device name for network devices currently
#	     configured, where n is 0 to MAX_NETDEVS - 1
#	     for example, NETDEV_0="ln0"
#
# IFCONFIG_n - ifconfig parameters for network devices currently
#	       configured, where n is 0 to MAX_NETDEVS - 1
#	       (see ifconfig(8) manual page)
#	       for example, IFCONFIG_0="130.124.1.20 netmask 255.255.255.0"
#
# RWHOD - "yes" if rwhod is enabled, blank or "no" if rwhod is disabled
#
# ROUTED - "yes" if routed is enabled, blank or "no" if routed is disabled
#
# ROUTED_FLAGS - routed flags (see routed(8) manual page)
#
# ROUTER - "yes" if the system is set up to be an Internet Protocol router,
#	   otherwise, blank or "no"
#
# GATED - "yes" if gated is enabled, blank or "no" if gated is disabled
#
# GATED_FLAGS - gated flags (see gated(8) manual page)
#
DISPLAYTYPE=
HOSTNAME="techjj.osa.dec.com"
NUM_NETCONFIG="1"
MAX_NETDEVS="24"
NETDEV_0="ln0"
NETDEV_1=
NETDEV_2=
NETDEV_3=
NETDEV_4=
NETDEV_5=
NETDEV_6=
NETDEV_7=
IFCONFIG_0="16.163.32.113 netmask 255.255.255.0 broadcast 16.163.32.255"
IFCONFIG_1=
IFCONFIG_2=
IFCONFIG_3=
IFCONFIG_4=
IFCONFIG_5=
IFCONFIG_6=
IFCONFIG_7=
RWHOD="no"
ROUTED="no"
ROUTED_FLAGS=
ROUTER="no"
GATED="no"
GATED_FLAGS=
PAGERAW="1"
PAGEFILE="/dev/rz3b"
PARTITION="rz3b"
PARTITIONTYPE="RZ26L"
PAGEMINSZ=0
PAGEMAXSZ=0
QUOTA_CONFIG=
export DISPLAYTYPE HOSTNAME NUM_NETCONFIG QUOTA_CONFIG
export NETDEV_0 NETDEV_1 NETDEV_2 NETDEV_3 NETDEV_4 NETDEV_5 NETDEV_6 NETDEV_7
export IFCONFIG_0 IFCONFIG_1 IFCONFIG_2 IFCONFIG_3 IFCONFIG_4 IFCONFIG_5
export IFCONFIG_6 IFCONFIG_7 RWHOD ROUTED ROUTED_FLAGS GATED GATED_FLAGS
export ROUTER MAX_NETDEVS
export PAGERAW PAGEFILE PARTITION PARTITIONTYPE PAGEMINSZ PAGEMAXSZ
LAT_SETUP="1"
export LAT_SETUP
BIND_CONF="YES"
export BIND_CONF
BIND_SERVERTYPE="CLIENT"
export BIND_SERVERTYPE
BIND_SERVERARGS="NONE"
export BIND_SERVERARGS
NFS_CONFIGURED="1"
export NFS_CONFIGURED
NFSSERVING="1"
export NFSSERVING
NONROOTMOUNTS="0"
export NONROOTMOUNTS
NUM_NFSD="8"
export NUM_NFSD
NUM_NFSIOD="7"
export NUM_NFSIOD
NFSLOCKING="1"
export NFSLOCKING
PCNFSD="1"
export PCNFSD
AUTOMOUNT="1"
export AUTOMOUNT
AUTOMOUNT_ARGS=""
export AUTOMOUNT_ARGS
NIS_CONF="YES"
export NIS_CONF
NIS_TYPE="MASTER"
export NIS_TYPE
NIS_DOMAIN="W_TechNIS"
export NIS_DOMAIN
NIS_ARGS="-s -S W_TechNIS,techjj.osa.dec.com,jaja.osa.dec.com"
export NIS_ARGS
NIS_PASSWDD="YES"
export NIS_PASSWDD



/etc/passwd (passwords were removed)

root:xxxx:0:1:system PRIVILEGED account:/:/bin/csh
nobody:*Nologin:65534:65534:anonymous NFS user:/:
nobodyV:*Nologin:60001:60001:anonymous SystemV.4 NFS user:/:
daemon:*:1:1:system background account:/:
bin:*:3:4:system librarian account:/bin:
uucp:Nologin:4:2:UNIX-to-UNIX Copy:/usr/spool/uucppublic:/usr/lib/uucp/uucico
uucpa:Nologin:4:2:uucp adminstrative account:/usr/lib/uucp:
auth:*:6:11:Authentication Subsystem:/tcb/bin:
cron:*:7:14:Cron Subsystem:/usr/adm/cron:
lp:*:8:12:Line Printer Subsystem:/users/lp:
tcb:*:9:18:Trusted Computing Base:/tcb:
adm:*:10:19:Administration Subsystem:/usr/adm:
ris:Nologin:11:21:Remote Installation Services Account:/usr/adm/ris:/bin/sh
wnn:Nologin:20:1:Wnn 4.109:/tmp:/bin/date
ftp:Nologin:25:10:Anonymous:/usr/ftp:/bin/date
guest:*Nologin:102:15:DEDnet-guest:/usr/users/guest:/bin/sh
+:



/var/yp/src/passwd (passwords were removed)

suruga:xxxx:103:15:Kazunari Suruga:/usr/users/suruga:/bin/csh
masada:xxxx:104:15:Sanshiro Masada:/usr/users/masada:/bin/csh
hayakawa:xxxxx:105:15:hayakawa:/usr/users/hayakawa:/bin/csh
foo:xxx:106:15:foo:/usr/tmp:



/var/yp/src/group ( this points to /etc/group)

system:*:0:root,suruga
daemon:*:1:daemon
uucp:*:2:uucp
mem:*:3:
kmem:*:3:root
bin:*:4:bin,adm
sec:*:5:
mail:*:6:mail
terminal:*:7:
tty:*:7:root
news:*:8:uucp
opr:*:9:root
auth:*:11:
lp:*:12:
lpr:*:12:root
backup:*:13:
cron:*:14:
users:*:15:suruga,masada,hayakawa
sysadmin:*:16:
tape:*:17:
tcb:*:18:
adm:*:19:adm
operator:*:20:
ris:*:21:
+:
9883.9and another possible check I'd tryfinder.uvo.dec.com::COFFEYJLa Feline Flooz - a unix catFri May 23 1997 07:479
>I believe so too, but where else can I check ???

I remember now the command I was trying to think of. 
cd /
/usr/lbin/fverify -n 
Then check /var/adm/smlogs/fverify.log



9883.10sys_check may helpKITCHE::schottEric R. Schott USG Product ManagementFri May 23 1997 15:589
Hi

 Run sys_check -noquick or -all

it will verify you setld inventories and show you either
checksum or protectin problems

http://www-unix.zk3.dec.com/tuning/tools/sys_check/sys_check.html

9883.11Non NIS loginSIOG::BR_MURPHYTue May 27 1997 05:5714
    What happens if you create a standard user, NOT under NIS control. If
    that works then you know there are no problems with access
    rights/permissions to shell/login files. The problem lies solely with
    the NIS setup.
    
    You could also try setting up an NIS user with /bin/ksh, just to verify
    the problem doesn't lie with /bin/csh
    
    Finally, have you compared the system login script on the MASTER Server
    & the CLIENT Server.../etc/profile & /etc/csh.login
    
    Brendan
    
    
9883.12Check path to shell, tooSMURF::MAJESKETue May 27 1997 12:234
    One more thing to check, check that each directory in the path to the
    shell is accessable to the users.  If any directory in the path is
    unaccessable to these users the login will fail in the way you
    describe.
9883.13JRDV04::SURUGAWed May 28 1997 02:3710
>/usr/lbin/fverify -n 

Finally this fixed the problem.  I selected few subsets
and gave a -y flag.  I have not looked at the fverify.log file
to check which file was causing the problem.  I may go check when
I get some time.

Anyway thank you for all your help provided in this topic. 

K. Suruga