Minor hiccups with CIFS Client

[Mike Keighley]

Have just installed cifsclient A.09.01.03 on L2000 HP-UX 11.00 with ntlm but no PAM-ntlm.

mount -F cifs ...
cifslogin ...
and cd, ls, touch etc. on the mounted share
... all seem basically ok.

Just a couple of possible quirks, which I would like to understand whether these are "real" issues please ?

quirk #1. Ch.7 of the manual (on the configuration file) and the comments in cifsclient.cfg itself both stress that the socket permissions are critical and should not be monkeyed with.
The defaults are:
//sockMode = 0600;
//sockOwner = "root"
//sockGroup = "wheel"

However the socket file itself (assuming I have found the correct one /var/opt/cifsclient/.cifsclient.sock ?) is

srw-rw-rw- 1 root root 0 Apr 26 16:22 .cifsclient.sock

surely 0600 should be srw------- ?

quirk #2. When I mount a windows share I consistently get an error about mnttab:

firebird:/ [147] # umask 022
firebird:/ [148] # mkdir /lms/ls01
firebird:/ [149] # mkdir /lms/ls01/software
firebird:/ [150] # mount -F cifs ls01:/software /lms/ls01/software
mount: unable to update mnttab
firebird:/ [151] #

this seems to be a fib, since the new mount IS in /etc/mnttab and the share is accessible.

(it might be worth mentioning that root has not done a cifslogin at this point, but I wasn't aware that it needs to, just to mount)

firebird:/ [151] # grep cifs /etc/mnttab
localhost:\\AIRDEV01\DOCUCORP /lms/airdev01/docucorp cifs soft,noac,retrans=3,ti
meo=200,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,NFSv3 0 0 1146066454
localhost:\\AIRPROD01\DOCUCORP /lms/airprod01/docucorp cifs soft,noac,retrans=3,
timeo=200,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,NFSv3 0 0 1146066721
localhost:\\LS01\SOFTWARE /lms/ls01/software cifs soft,noac,retrans=3,timeo=200,
acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,NFSv3 0 0 1146140271
firebird:/ [152] #

As stated, these do not seem to be show-stoppers, just seeking confirmation whether this is expected behaviour, doc. error or what please ?

[Steven E. Protter]

Shalom,

I reccomend the following.

Do a cifslogin as root and see if the results are the same.

Install a newer, supported version of CIFS.
http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=B8724AA

Hopefully they still offer it for 11.00

Reboot required.

SEP

[Mike Keighley]

Steven,

Doing a cifslogin as root frankly doesn't make much sense to me as
(a) I don't have a Windows user "root"
(b) the manual is fairly clear that I should "mount" first and "cifslogin" after.

However ...
firebird:/var/opt/cifsclient [183] # cifslogin ls01 mike
Remote user mike's password:
Logging in User: Server not connected!
firebird:/var/opt/cifsclient [184] # cifslogin airdev01 mike
Remote user mike's password:
firebird:/var/opt/cifsclient [185] #
firebird:/var/opt/cifsclient [186] # mount -F cifs ls01:/software /lms/ls01/software
mount: unable to update mnttab
firebird:/var/opt/cifsclient [187] #

... so yes it still gives the same (apparently spurious) error

On your "later version" question, I followed your link and got
"NOTE: As a convenience for HP-UX 11.0 customers, the most recent version of CIFS Client for HP-UX 11.00 (A.01.09.03) remains available for download."

[Mike Keighley]

It's probably bad etiquette to reply to myself, but I think I have a partial answer on quirk #1:

I uncommented sockMode=0600 and restarted cifs. I immediately noticed that non-root users could no longer run cifslist, no big deal.

But then I got errors with cifslogin and cifslogout:
firebird:/home/gpg [50] $ cifslogin ls01
Remote user mike's password:
ipcclient: error connecting to daemon: [13] Permission denied
ipcclient: CIFS Client is down.
firebird:/home/gpg [51] $ cifslogout ls01
ipcclient: error connecting to daemon: [13] Permission denied
ipcclient: CIFS Client is down.
firebird:/home/gpg [52] $

Needless to day, CIFS Client ISN'T down, it just won't talk to this user.

So, I guess that now begs the question:

Has the default sockMode been deliberately changed from 0600 to 0666 to fix this issue ? and someone simply forgot to update the manual and the comments in the .cf file ?

or, is the default sockMode 0666 a bug ?

For now, I can obviously put sockMode back to the default, and that will work, but considering the strong language in the manual such as "Do not set these values to anything other than 0600 ... unless you really know what you are doing." and "used to provide strong authentication of the user", I can't help feeling that sockMode=0666 has got "security hole" written all over it.

Thoughts please ?

What are the socket permissions on these "later versions" that you are all running please ?

Pity I haven't got time to hit on the socket as a guest user, and see what it will do for me. Back to work ...

[Eric Raeburn]

Hello, Mike,

Eric from the HP CIFS Client Lab here.

Sorry for the confusion; the admonitions about mode 0600 are obsolete. The default is 0666; without this, as you saw, users cannot communicate with the cifsclient daemon. The "old" value (0600) worked when the "runAsUser" parameter was set to the "anyone" value, but that caused other problems. 0666 is also the default in all subsequent cifsclient releases.

Regarding your "unable to update mnttab" error, we have never seen this. I just tried setting the mode of the mnttab file to 444 and still did not get the error. I suggest filing an official support call if this problem persists.

-Eric

[Mike Keighley]

Eric,

Thanks for the explanation about sockMode 0666.

As for the mnttab error, I think I will wait at least until the next reboot, before reporting it.

In the meantime, I think I have turned up quirk #3 (sorry !) :

bdf -l is supposed to report only "local" filesystems. It correctly excludes nfs mounts, but does not exclude cifs mounts.

firebird:/etc/opt/cifsclient [9] $ bdf -l
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 143360 35548 101163 26% /

/dev/vg01/lvol8 1572864 37770 1439259 3% /clients/adt
/dev/vg01/lvol20 2097152 905698 1117084 45% /clients/abbsta
localhost:\\AIRPROD01\DOCUCORP
286711784 5530240 281181544 2% /lms/airprod01/docucorp
localhost:\\AIRDEV01\DOCUCORP
286742504 24069704 262672800 8% /lms/airdev01/docucorp
bdf: /lms/ls01/software: Permission denied
firebird:/etc/opt/cifsclient [10] $

known bug ? side effect of having "localhost:" as the remote server name ?

[Eric Raeburn]

Mike,

You are observing bdf behavior before it was "aware" of CIFS as a filesystem on hpux. This has been fixed in hpux 11.23 (also known as hpux 11i v2), and future hpux releases. It is not fixed in 11.11 (11i v1).

Please post any other anomalies you discover with the CIFS Client.

Best,
-Eric

[Mike Keighley]

Eric,

Thanks again. I guess I shall just have to live with that one !

Last one coming up, I think ... several years ago I had installed CIFSclient A.05 or 06 for one user to be able to write to a particular W2K server. It never worked well due to bugs which were later fixed in W2K SP3. Also the password change and account lockout integration was flakey.

I abandoned it, and uninstalled it over 3 years ago.

After installing A.09, this user was repeatedly locked out of his Windows AD account. We deduced from the logs and from cifslist that he effectively had a cached "cifslogin ls01" from somewhere, plus his passwords were out-of-sync.

He had not explicitly done cifslogin, or tried to access the share on ls01. ls01 is not even the server he had been using before.

He wasn't cached in the cifs user database, as that had been deleted in the interim.
Nothing in his profile, .ENV etc.

"cifslogout ls01" + a password reset, has sorted him out, but it is a mystery where cifsclient might have had his years-old login cached.

[Eric Raeburn · Accepted solution]

Mike,

Regarding the apparently-long-cached cifslogin credentials, without direct contact to the system I would not want to speculate about what happened. It's conceivable the user's credentials were stored via PAM-NTLM, if you used that; the new installation would still attempt to use those. If you did 'swremove' long ago, then then cifsclient user database, /var/opt/cifsclient/cifsclient.udb, as you state, would have been removed. That is the only place the cifs client stores users' login credentials.

Regarding the "bdf -l" issue, if it is very important to you, you could ask your hp support representative what their policy is for giving revised binaries to customers. I've no idea if it's allowed, but if it is, I could forward them a "cifs-aware" bdf for you. Otherwise, it would be simple for you to create a shell wrapper for bdf that does "grep -v cifs" if you give it "-l".

BTW, I've fixed the comments on sockMode, thanks to your observations, and it will be fixed in the next release of the Admin Guide as well.

-Eric

[Mike Keighley]

Eric,

Agreed that cifsclient.udb cannot be the cache problem. Pam-NTLM is unlikely; I was using it last time, but NOT this time; it isn't setup in /etc/pam.conf

At least we have confirmed there aren't any other cache locations I need to clean out.

On bdf -l, the idea of using a forward version is intriguing, but given that we have frozen on 11.0 for stability reasons, it might not be the best choice.

I think your suggestion of a shell wrapper is probably safer, thanks.

I think that just about covers it.

You may be pleased to hear that, as of last night, CIFSclient is doing live work and saving my colleagues from getting up in the middle of the night to do a couple of FTPs.
Heartfelt appreciation from them to the whole CIFS team !

[Eric Raeburn]

Thanks, Mike.

-Eric