file and dir perms with cifs

[Charles T Fischer]

I have mounted a 2000 share on my hpux 11i box via cifs. Share was created with Domain level Group Perms on the share (as opposed to perms on the dir which i tried with no love). Filesystem was mounted on unix side with cifs using a domain admin username and password. Problem is all files and dirs show up on the unix side with rwx for all and with owner as root. How do i fix this?? Not sure if i should be focusing on PAM, smb.conf, pam/smb.conf, cifsclient.cfg or the other 8 billion files associated with cifs samba and pam. Any advice appreciated!

[harry d brown jr]

Now now, there are only 7 billion config files!

What are the permissions on the M$ side?

Oh wait - You logged in as a DOMAIN ADMIN? That probably explains it. Try a regular user login.

live free or die
harry

[Charles T Fischer]

demoted the acct to domain user, no difference.

[Eric Raeburn]

Charles,

Sorry for the late reply; I've been out of the office.

Unfortunately, you are trying to solve a problem for which there is no perfect solution. The problem is getting Windows file attributes to be displayed by 'ls -l' on a Unix filesystem. The two models are too
different to do this adequately (the Windows user id would somehow have to be mapped to a Unix user id, a difficult problem with bad performance ramifications; the notion of 'group' ownership on a file is different;
Unix directory listings have no cogent way of representing Windows ACLs, etc.). The Unix file attributes one would like to display simply do not have exact counterparts in the Windows filesystem.

The CIFS Client always displays the user's Unix login name in the long listing: if you are root on HP-UX and logged into the Windows system as Bob, and you do 'ls -l' on the mounted directory, files will appear as owned by root; if you are 'alice' on the HP-UX system and logged into the Windows system as XYZ and you do 'ls -l' on the mounted dir, the same files will appear as owned by alice.

To get a long directory listing, the CIFS Client sends standard "find first" and "find next" requests, to which the server sends back only file names, sizes, and DOS attributes. In order for the CIFS Client to
pass complete 'ls -l' data to the operating system for display on the console, it has to simulate the rest of the data, which it does not have. Even if all the data were there, it does not translate unambiguously to Unix filesystem data.

There are three things you can do to influence the output of 'ls -l':

(1) The CIFS Client allows you to use the Unix 'execute' bit to represent any DOS attribute, like "hidden" or "archive". This is done through the execMapping parameter in cifsclient.cfg. The default is "on", so files on a mounted Windows server will always have the execute bit on (without this, you cannot invoke an executable file stored on a mounted Windows server). If you set it, for example, to "archive", then files on the
Windows server whose archive bit is set will appear on the HP-UX client with the execute bit on.

(2) The Windows filesystem has no notion of directory size, so for directories on a mounted Windows server, the CIFS Client displays an arbitrary "faked" size of 131072 (128 Kb) in 'ls -l'. You can set this to another, more commonly seen value, like 96 or 1024, but remember it is just a faked symbol; it represents a quantity that is meaningless on the Windows system.

(3) This will probably be impractical, for you but, if the server is a Unix-type OS (HP-UX, Linux, etc.) running a recent version of Samba (the "HP-UX CIFS Server" for example), you can enable the CIFS Unix Extensions. This allows the Client and Server to exchange Unix file attributes, so
long directory listings display actual Unix file ownership and permissions. This is our recommended solution for customers for which this is important.


-Eric Raeburn
HP CIFS Client Lab

[Charles T Fischer]

Eric...

You sound like you know what you're talking about with this...would it be possible for you to give me a call? I'd like to discuss this further with you. Please send me an email if possible to micheper@clientlogic.com and i'll send you my phone number. Thanks.

[Eric Raeburn]

Charles,

I am sorry, but there is an established protocol at HP for support issues. The first choice for customer inquiries is HP's large (and very capable) support organization. Any issue they cannot resolve will be passed to us in the development lab.

I recommnend any of the following:
(1) continue this dialog in the hp IT forum (I'm happy to reply to your inquiries here),
(2) contact your hp support rep,
(3) check out the CIFS Client Admin Guide at docs.hp.com .

Thanks for your understanding,
-Eric Raeburn

[Charles T Fischer]

ok, that works. My main concern is locking down the mount from the unix side. It is indeed HPUX 11i. I can add matching accounts to the password file or groups to the group file but there must be a mechanism in cifs/samba to map the two together (similiar to services for unix and nfs). Or, if there is no way to secure the unix side to limit user access, just let me know. Will enabling the CIFS Unix Extensions provide some security?

[Eric Raeburn]

Charles,

You can experiment with permissions on the Windows side, but not everything works as expected. For example, I have found that setting "deny all" on the Windows side will prevent an HPUX CIFS Client user, logged into the Windows server as a non-owner of the file, from removing it. But setting "read-only" (again on the Windows side) does not.

There currently is no way of mapping Unix users (or groups) between the cifsclient/unixhost and the windows server. As I mentioned previously, the implementation of ACLs in Windows is so different from the ownership model on Unix that such a mapping not would be unambiguous.

Samba is an open source emulator of the Windows file and print server. It is designed to run on Unix or Linux. CIFS Unix Extensions are not avaiable on Windows, but are implemented in recent versions of Samba (including the HP CIFS Server, which is based on Samba) as well as the HP CIFS Client. I mentioned earlier that this solution may not be practical for you, since it would mean migrating your file servers from Windows to Unix. However, that would provide a straightforward, unambiguous, and homogenous environment for enforcing file attributes, including user and group ownership, and "rwx" permissions.

If solving this problem is important enough to you that you would consider such a migration, please research other aspects of it carefully first. For example, the current version of the HP CIFS Server does not support NTLMv2 or Kerberos authentication (Samba 3.0 does, but has not yet been released by HP).

Please post if you have any further questions.

-Eric

[Charles T Fischer]

so the bottom line is, the filesystem cannot be locked down on the unix side. that's all i needed, thanks.