CIFS Client Team: Issue with touching a file "touch: cannot change times on zzz"

[Alzhy]

I am running the latest CIFS CLient software and my mount is from a CIFS Server. The MOunt is RW...


Any clues?

[Steven E. Protter]

Nelson,

What touch command specifically are you using. There are command line options that should force it.

Note also there was a security bulliten on CIFS Client and Server this week with a new version. The flaw you encountered could be version specific. Anyway for security concerns you should obtain and install the new version and then re-test.

SEP

[spex]

Hi Nelson,

Is this a Windows server? Is the file open by another program/user?

PCS

[Alzhy]

Eric or any of the CIFS/Sharity Team or anyone who understands:

We are using A.02.01.02 with the "new way" of mounting and new cifsclient.cfg setup. My existing cifsclient.cfg config already has a serve .default config. So what I essentially did, is have the user simply perform a cifsmount //cifssrvr/share /hispath/mnt and have provided a username and password.

The user can navigate and edit, etc... it is just when he tests the mount via the touch command (either a new file or an existing file) that he gets the error...

Do I need a new server definition block defined in cifsclient.cfg?

[Alzhy]

Here's some additional details:

The CIFS Server (SAMBA) has SECURITY = SHARE. And the share in question accepts guest connections and is shared out wide open R/W.

User root can cifsmount it, perform normal file operations (remove files, edit files, etc..). But when a non-root user access the mounted filesystem - "permission denied".

But if the non-root user performs the cifsmount himself, he can access (navigate, view) the mounted share but cannot perform any edits and a simple touch on a file results inthe above message....

[Steven E. Protter]

Shalom Nelson,

This is the exact behavior I received with Samba For Linux on RH 3/4.

It is the default behavior or samba though I thought HP had fixed that with CIFS.

The solution is to have the indvidual users perform the mount after permitting the cifsmount program to non-root users.

SEP

[Alzhy]

SEP,

Aplogies BUT, CIFS Client is NOT Samba...

And CIFS Client software I believe is not widely available on Linux as Linux has full support for smbfs .

[Eric Raeburn · Accepted solution]

Hello, Nelson,

Several points:

1. The CIFS Client version to which you refer, A.02.01.02, does not exist. From what you describe, you are certainly using A.02.01.

2. The notion of non-root mounting filesystems is a bug we accidentally let slip out in A.02.01. It is fixed in the current version, A.02.02. Only root is permitted to mount filesystems. (There are a lot of other improvements in A.02.02; I encourage you to upgrade. You can review these in the Release Notes at docs.hp.com).

3. You do not need to modify the cifsclient configuration file in any way to use share-level security; that is set up on the Samba server.

Here's how the HP CIFS Client and Server handle user-level security. Admittedly rather quirky, but it works; you just have to follow the rules.

i. In the Samba configuration file, under the entry for the share, you give a list of one or more usernames. These are the users whose passwords are used by Samba to authenticate client requests to access the share (this will make sense later). For example:

[global]
security = share
encrypt passwords = yes

[share]
path = /export/share
username = userA userB

ii. On the cifsclient, root mounts the share:

cifsmount server:/share /mountpoint

Root may also provide a username and password (-U and -P), subject to constraints described below.

iii. On the cifsclient, whoever wants to access the share must be autheticated via cifslogin:

cifslogin [-U username] //server/share
Share Password for \\SERVER\SHARE:****

Note that if you use this syntax:

cifslogin [-U username] server

you will first get this prompt:

Login to Share:

which is asking for the share name; then you will get the "Share Password..." prompt.

iv. Now, here is the first non-intuitive aspect of this feature. It doesn't matter what username is given in cifslogin. It matters only what password is given. Samba compares this password (encrypted of course) with the smb passwords of the usernames specified in smb.conf (userA and userB in my example above). If a match is found, the cifslogin succeeds and the user on the client is logged into the server and can access the share. (This is the behavior I said in item i. would "make sense later".)

In fact, it doesn't matter what the user's Unix login name is on the client, or if the username given with the -U option even exists on either system. Only the password is significant.

v. Now on the cifsclient a non-intuitive thing happens. For as long as the server is mounted, any future users who do cifslogin to that share must use the same password that was used for the initial cifslogin. This is because, for share-level security, the cifsclient does not transmit these subsequent cifslogins to the server; it caches the first successful password used (encrypted, of course), and compares it to any subsequent attempts, in essence doing its own authentication for the share.

vi. This immediately begs the question, why should all my users know userA or userB's passwords? They shouldn't. The best way to set this up is to use a dummy user for the share (in the username parameter in smb.conf); then the users on the cifsclient will always use the dummy user's password to access the share. The dummy user must be created on the Samba server as both a unix user (useradd(1M)), and as a Samba user (smbpasswd). The users on the cifsclient do not need to know anything about this dummy user; they need to know only the password for the share, which just happens to be the dummy user's password on the server.

vii. There is an exception to the rule in item v. Once any non-root user has been autheticated (via cifslogin) by the server for the share, root can access the share, without doing cifslogin.

I hope this is comprehensible. Please post your results or any follow-up questions.

-Eric