[SOLVED] disable/enable C-Shell Script (CSH) for certain user

yoachan · 08-08-2011, 10:46 AM

Dear all,

is there any way to enable/disable csh script only for one/certain user(s).
I ask this because one of my user can no longer use a csh script while others can. Even a simple helloworld

Code:

#!/bin/csh
echo "helloworld"

returns nothing. No error, no result, nothing.
while other users having no problem with csh script.
It happens after I did a WHM upgrade, and when I realized...

I don't think it's permission for /bin/csh

Code:

admin@box [/home/admin]# ll /bin/csh
lrwxrwxrwx 1 root root 4 Nov  5  2010 /bin/csh -> tcsh*
admin@box [/home/admin]# ll /bin/tcsh
-rwxr-xr-x 1 root root 352904 Nov  4  2010 /bin/tcsh*

What I want is to re-enable this user so that it can use csh script again. Any ideas?
Thanks in advanced.

Regards,

Yoachan

Nominal Animal · 08-09-2011, 04:07 AM

Check ~user/.tcshrc and ~user/.cshrc files. The tcsh shell reads those (the first one that it finds) every time it starts, for example when executing a script. Most likely the user has put something in there that makes tcsh abort before doing anything worthwhile.

yoachan · 08-14-2011, 02:09 AM

Nominal Animal: Thank you for your reply and sorry for my late answer...

I've search my machine, and can't find any .tcshrc or .cshrc but a file .tcshrc owned by root that located in /root that contains

Code:

# .tcshrc

# User specific aliases and functions

alias rm 'rm -i'
alias cp 'cp -i'
alias mv 'mv -i'

set prompt='[%n@%m %c]# '

I even copy this file in my /home/admin (and change owner as 'admin') but still no luck....

Nominal Animal · 08-14-2011, 07:56 AM

Quote:

Originally Posted by yoachan

I've search my machine, and can't find any .tcshrc or .cshrc

If only one user is affected, then it should be in that user's home directory. That's what ~user/ refers to. That is the most likely culprit, although if they do not exist, the problem could lie in other shell startup files for that user, like .profile or .login .

If all the shell startup files are in order, then it could be a SELINUX problem; perhaps you have changed the security context for that user?

yoachan · 08-18-2011, 08:49 PM

@Nominal Animal: Thanks for your reply

Quote:

Originally Posted by Nominal Animal

If only one user is affected, then it should be in that user's home directory. That's what ~user/ refers to. That is the most likely culprit, although if they do not exist, the problem could lie in other shell startup files for that user, like .profile or .login .

That two files are not exist in any user.....
the admin user used to have a .history file that only contains one command:

Code:

exit

I've already remove that code, but still no luck....

Quote:

Originally Posted by Nominal Animal

If all the shell startup files are in order, then it could be a SELINUX problem; perhaps you have changed the security context for that user?

The only thing that I can tell from SELINUX is that it's status is SELINUX=disabled with SELINUXTYPE=targeted

still stuck ....

Nominal Animal · 08-20-2011, 11:29 AM

You have SELINUX disabled, so it cannot be a cause of this problem. I still think the problem lies in the shell startup files.

Can you run this command as the problematic user, and as another user who has no issues with csh scripts?

Code:

strace -f csh -c 'true' 2>&1  | sed -ne 's|^open("\([^"]*\)",[^)]*) = [0-9]*$|\1|p'

The command will list the files the csh opens (using a successfulopen syscall) when it starts up. It includes libraries ( .so files), not all of them are shell scripts.

I believe the problem lies in one of the script files listed by the above command for the problematic user, and that the list must be different for the problematic user than for a user who has no issues with csh. If the lists differ, perhaps you could show the offending file here?

(Alternatively, one of the common script files could have a test using the [FONT=Monospace] id [FONT]command or the USER environment variable, which only matches the problematic users, and causes the shell to exit prematurely. I think this is highly unlikely though, because non-user-specific shell startup files are owned by root. Such changes would have to have been made by somebody with root access, in other words.)

yoachan · 08-21-2011, 12:17 AM

@Nominal Animal:
Thank you for your answer.
You were right, there are differences between the results.

Here's result for a non problematic user

Code:

/lib64/libtermcap.so.2
/usr/lib64/gconv/gconv-modules.cache
/lib64/libnss_files.so.2
/home/myuser/.history

while /home/myuser/.history is actually an empty file.
And here's result for another non problematic user

Code:

/lib64/libtermcap.so.2
/usr/lib64/gconv/gconv-modules.cache
/lib64/libnss_files.so.2

Here's the result for my blocked user:

Code:

/lib64/libtermcap.so.2
/usr/lib/locale/locale-archive
/usr/share/locale/en/LC_MESSAGES/tcsh
/usr/lib64/gconv/gconv-modules.cache
/lib64/libnss_files.so.2
/etc/profile.d/
/dev/null
/etc/profile.d/colorls.csh
/dev/null
/etc/profile.d/glib2.csh
/dev/null
/etc/profile.d/krb5-devel.csh
/dev/null
/etc/profile.d/krb5-workstation.csh
/dev/null
/etc/profile.d/lang.csh
/usr/share/locale/en/LC_MESSAGES/tcsh
/dev/null
/etc/profile.d/less.csh
/dev/null
/etc/profile.d/locallib.csh

file /etc/profile.d/locallib.csh contains this code:

Code:

#cPanel Added local::lib -- BEGIN
setenv LOCALLIBUSER $USER
if ( -e /usr/bin/whoami ) then
        setenv LOCALLIBUSER `whoami`
endif
if ( "$LOCALLIBUSER" != "root" ) then
    eval $(perl -Mlocal::lib)
endif
#cPanel Added local::lib -- END

and when I execute it, I got this errors:

Code:

# /etc/profile.d/locallib.csh
/etc/profile.d/locallib.csh: line 2: setenv: command not found
/etc/profile.d/locallib.csh: line 10: syntax error: unexpected end of file

Nominal Animal · 08-21-2011, 10:46 AM

@yoachan: Those differences between users are quite surprising. Normally, I'd expect the only differences to be in per-user files. Perhaps the actual shell run for the problematic user is different. Could you check what the commands

Code:

file `which csh`
strace -f /bin/csh -c 'true' 2>&1  | sed -ne 's|^open("\([^"]*\)",[^)]*) = [0-9]*$|\1|p'

output for a problematic and for a working user?

You see, this output:

Quote:

Originally Posted by yoachan

Code:

# /etc/profile.d/locallib.csh
/etc/profile.d/locallib.csh: line 2: setenv: command not found
/etc/profile.d/locallib.csh: line 10: syntax error: unexpected end of file

does not really make sense; it looks like the .csh file was run by a sh shell. Did you remember to source it (as they are intended to be), i.e. using

Code:

csh -c 'source /etc/profile.d/locallib.csh'

yoachan · 08-22-2011, 10:08 PM

@Nominal Animal: Thank you again for your reply

Quote:

Originally Posted by Nominal Animal

@yoachan: Those differences between users are quite surprising. Normally, I'd expect the only differences to be in per-user files. Perhaps the actual shell run for the problematic user is different. Could you check what the commands

Code:

file `which csh`
strace -f /bin/csh -c 'true' 2>&1  | sed -ne 's|^open("\([^"]*\)",[^)]*) = [0-9]*$|\1|p'

output for a problematic and for a working user?

Here's for worked user:

Code:

# file `which csh`
/bin/csh: symbolic link to `tcsh'

# strace -f /bin/csh -c 'true' 2>&1  | sed -ne 's|^open("\([^"]*\)",[^)]*) = [0-9]*$|\1|p'
/lib64/libtermcap.so.2
/usr/lib/locale/locale-archive
/usr/share/locale/en/LC_MESSAGES/tcsh
/usr/lib64/gconv/gconv-modules.cache
/lib64/libnss_files.so.2
/home/myuser/.history

and here's for problematic user:

Code:

# file `which csh`
/bin/csh: symbolic link to `tcsh'

# strace -f /bin/csh -c 'true' 2>&1  | sed -ne 's|^open("\([^"]*\)",[^)]*) = [0-9]*$|\1|p'
/lib64/libtermcap.so.2
/usr/lib/locale/locale-archive
/usr/share/locale/en/LC_MESSAGES/tcsh
/usr/lib64/gconv/gconv-modules.cache
/lib64/libnss_files.so.2
/etc/profile.d/
/dev/null
/etc/profile.d/colorls.csh
/usr/share/locale/en/LC_MESSAGES/tcsh
/dev/null
/etc/profile.d/glib2.csh
/dev/null
/etc/profile.d/krb5-devel.csh
/dev/null
/etc/profile.d/krb5-workstation.csh
/dev/null
/etc/profile.d/lang.csh
/usr/share/locale/en/LC_MESSAGES/tcsh
/dev/null
/etc/profile.d/less.csh
/dev/null
/etc/profile.d/locallib.csh

Quote:

Originally Posted by Nominal Animal

You see, this output:

does not really make sense; it looks like the .csh file was run by a sh shell.

In some way I think it's due to the script didn't state #!/bin/csh in it's first line.....

Quote:

Originally Posted by Nominal Animal

Did you remember to source it (as they are intended to be), i.e. using

Code:

csh -c 'source /etc/profile.d/locallib.csh'

for that command you requested, here's the result for both users:

Code:

# csh -c 'source /etc/profile.d/locallib.csh'
Illegal variable name.

but here's the fun part. For the problematic user, I tried a simple script echoing "Hello World":

Code:

# cat dummy.csh
  #!/bin/csh
  echo "Hello World"

# csh -c 'source ~/bin/db_backup/dummy.csh'
  Hello World

it displays the correct result.

Nominal Animal · 08-23-2011, 03:47 PM

Quote:

Originally Posted by yoachan

In some way I think it's due to the script didn't state #!/bin/csh in it's first line.....

No; you see, they are not really standalone scripts, but just snippets that are run by the same shell. They mostly set up environment variables and stuff like that.

You should think of source as include: it does not execute the argument as a separate thing, but includes it into the current shell, just as if you had typed or included those files in the script itself. All shells support this.

Quote:

Originally Posted by yoachan

Code:

# csh -c 'source /etc/profile.d/locallib.csh'
Illegal variable name.

This is the file that causes the problem. Note that the working shells did not read this file.

Although all your users use the same shell, it is in a different mode. A shell can be a login shell, an interactive shell, a combination of the two, or a non-login non-interactive shell. Really, the only difference between these modes are the files the shell sources at startup. Different shells have different modes, but that's not important right now: all you need to understand is that depending on how and why csh or tcsh is run, it sources different files when it starts, and that the abovementioned file has a problem which causes the shell to fail before doing anything. (The man pages do list the files for each shell, but it is very convoluted. I don't recommend worrying about those unless you really have to; they confuse me too. I sometimes just end up doing the strace instead of working thorough the documentation!)

"Illegal variable name" is actually quite helpful error message. It usually occurs when you accidentally insert a control character, or replace an ASCII letter with an accented one -- say, an Unicode glyph that looks almost the same. In other words, /etc/profile.d/locallib.csh almost certainly has a typo in it. The other possibility is a problem in the Perl bit.

To check if the file has invalid characters in it, could you run and show the output for

Code:

hexdump -C /etc/profile.d/locallib.csh

This will display every byte in that file in hexadecimal, with ASCII representation on the right. It is the same for all users, so it is enough to run it for one user only.

That script also sources some code Perl should output. It seems strange to me, but what would I know.. Anyway, if you could run (for a working and a nonworking user) and show the output of

Code:

perl -Mlocal::lib | hexdump -C

we could make sure the error does not lie there.

If there is something you'd like to keep private in the above output, you can obfuscate the output by replacing each character with X; just remember to replace the hexadecimal number on the left side with XX too.

Quote:

Originally Posted by yoachan

but here's the fun part. For the problematic user, I tried a simple script echoing "Hello World":

Code:

# cat dummy.csh
  #!/bin/csh
  echo "Hello World"

# csh -c 'source ~/bin/db_backup/dummy.csh'
  Hello World

That command starts a new csh shell in a mode where the profile files are not sourced. Because in that mode csh does not source /etc/profile.d/locallib.csh which causes the failure, your command succeeds!

yoachan · 08-23-2011, 10:47 PM

@Nominal Animal: Thank you that you still bear with me

Quote:

Originally Posted by Nominal Animal

To check if the file has invalid characters in it, could you run and show the output for

Code:

hexdump -C /etc/profile.d/locallib.csh

Here's the result for hexdump:

Code:

# hexdump -C /etc/profile.d/locallib.csh
00000000  23 63 50 61 6e 65 6c 20  41 64 64 65 64 20 6c 6f  |#cPanel Added lo|
00000010  63 61 6c 3a 3a 6c 69 62  20 2d 2d 20 42 45 47 49  |cal::lib -- BEGI|
00000020  4e 0a 73 65 74 65 6e 76  20 4c 4f 43 41 4c 4c 49  |N.setenv LOCALLI|
00000030  42 55 53 45 52 20 24 55  53 45 52 0a 69 66 20 28  |BUSER $USER.if (|
00000040  20 2d 65 20 2f 75 73 72  2f 62 69 6e 2f 77 68 6f  | -e /usr/bin/who|
00000050  61 6d 69 20 29 20 74 68  65 6e 0a 20 20 20 20 20  |ami ) then.     |
00000060  20 20 20 73 65 74 65 6e  76 20 4c 4f 43 41 4c 4c  |   setenv LOCALL|
00000070  49 42 55 53 45 52 20 60  77 68 6f 61 6d 69 60 0a  |IBUSER `whoami`.|
00000080  65 6e 64 69 66 0a 69 66  20 28 20 22 24 4c 4f 43  |endif.if ( "$LOC|
00000090  41 4c 4c 49 42 55 53 45  52 22 20 21 3d 20 22 72  |ALLIBUSER" != "r|
000000a0  6f 6f 74 22 20 29 20 74  68 65 6e 0a 20 20 20 20  |oot" ) then.    |
000000b0  65 76 61 6c 20 24 28 70  65 72 6c 20 2d 4d 6c 6f  |eval $(perl -Mlo|
000000c0  63 61 6c 3a 3a 6c 69 62  29 0a 65 6e 64 69 66 0a  |cal::lib).endif.|
000000d0  23 63 50 61 6e 65 6c 20  41 64 64 65 64 20 6c 6f  |#cPanel Added lo|
000000e0  63 61 6c 3a 3a 6c 69 62  20 2d 2d 20 45 4e 44 0a  |cal::lib -- END.|
000000f0

Quote:

Originally Posted by Nominal Animal

Anyway, if you could run (for a working and a nonworking user) and show the output of

Code:

perl -Mlocal::lib | hexdump -C

we could make sure the error does not lie there.

perl -Mlocal::lib | hexdump -C returns nothing for either users....

Is it possible if somehow I just make csh to skip those included files? Because the worked users seems to have less file include lines compared with problematic users...?

Nominal Animal · 08-25-2011, 05:31 PM

Quote:

Originally Posted by yoachan

Here's the result for hexdump:

Thanks. It is clean, no extra characters there.

Quote:

Originally Posted by yoachan

perl -Mlocal::lib | hexdump -C returns nothing for either users....

Well, that's the problem, then.

I did a little more digging, and found the reason. It is pure cPanel stupidity. The /etc/profile.d/locallib.csh file breaks for every single tcsh user. You, like many others, really use tcsh (instead of a "native" csh). It is very surprising, and I'm a bit miffed I didn't think to check earlier.

Fortunately, the fix is trivial. Replace $(perl -Mlocal::lib) with `perl -Mlocal::lib` ; after the replacement your /etc/profile.d/locallib.csh should contain

Code:

#cPanel Added local::lib -- BEGIN
setenv LOCALLIBUSER $USER
if ( -e /usr/bin/whoami ) then
        setenv LOCALLIBUSER `whoami`
endif
if ( "$LOCALLIBUSER" != "root" ) then
    eval `perl -Mlocal::lib`
endif
#cPanel Added local::lib -- END

Or, you can just remove the entire file. It's only useful for cPanel developers who use Perl. (I think the cPanel bug reports recommend just deleting the file. Any cPanel Perl developers can always add something similar to their own profile files, if they really need it, after all.)

I hope this solves your problem. (If it does, please remember to prepend [SOLVED] to the thread title.)

yoachan · 08-26-2011, 09:27 AM

@Nominal Animal:
Again, and again, thanks for your reply.
As you said, that solution works like a charm........

Thank you so so much for your helps

really appreciated.

Yes, case is closed, I'll marked it as "SOLVED"

regards,

Yoachan