Operating System - OpenVMS
Showing results for 
Search instead for 
Did you mean: 

CIFS for OpenVMS / Shared (among VMS users) Directories

Go to solution

CIFS for OpenVMS / Shared (among VMS users) Directories

We have been using shared directories in VAX/VMS and OpenVMS for decades; calling them "areas" here. The convention defines an area "foo" to consist of a logical name pointing to a disk, two rights identifiers, and three pairs of ACEs on the top level directory:

$ dir area$foo:[000000]foo.dir/sec

Directory AREA$FOO:[000000]


Total of 1 file.

Rights identifier FOO is the owner of the area; this identifier has the RESOURCE attribute and is granted to user accounts that are supposed to have full access to the area. FOO_R is granted to accounts that shall have read-only access. We don't currently use disk quotas, but it would be easy to create a quota entry for FOO and share the quota among holders of the identifier.

With PATHWORKS / Advanced Server, we were able to serve areas to users of an AD domain by reflecting the rights identifiers as AD groups and trusting the AD domain from an older NT domain to which Advanced Server is joined.

Now, here comes CIFS for OpenVMS, currently on a test cluster with no production users, and I am trying to serve the above area to PC users. The Samba-based server is a member of the AD domain (using SECURITY=DOMAIN until SECURITY=ADS will be supported), so the group business should get even easier now. This is a new test environment, there are no PATHWORKS ACEs remaining anywhere: AS was never installed in this cluster.

After several core dumps, I found a trace of something called "patch sets", which appear to be some kind of "micro-ECOs", and I am now running CIFS for OpenVMS V1.1 ECO1 PS009.

The stanza for area foo in SMB.CONF is:

comment = Samba Access Control Test Share
path = /area$%S/%S
valid users = @%S, @%S_R
inherit owner = yes
vfs objects = varvfc
read only = no

I have created group mappings (NET GROUPMAP) for FOO and FOO_R like this (DCL symbol WSU supplies the "-W", "-S", and "-U" options):

$ net groupmap list verbose ntgroup=foo 'wsu
SID : S-1-5-21-314829432-2818312396-2276735868-1009
Unix gid : -2147418098
Unix group: FOO
Group type: Local Group
Comment : Local Unix group
$ net groupmap list verbose ntgroup=foo_r 'wsu
SID : S-1-5-21-314829432-2818312396-2276735868-1010
Unix gid : -2147418097
Unix group: FOO_R
Group type: Local Group
Comment : Local Unix group

Using NET RPC GROUP ADDMEM, I can make AD users or groups into members of these local groups, and this mechanism is supposed to provide appropriate access controls for Windows users.

Unfortunately, I already had to cancel an upgrade project because access rights don't work out as expected:

(1) OpenVMS users who have full privileges can access ANY file in ANY CIFS share, regardless of AD group membership and other access controls. It seems like SYSPRV is the one bit that counts.

(2) OpenVMS users with only TMPMBX and NETMBX cannot access any area (as defined above) through CIFS, even if they are (directly or indirectly through an AD group) member of the above local group FOO.

(3) On many occasions (such as a Vista user attempting to delete a file in AREA$FOO, while the user is only member of FOO_R and hence is denied write/delete access), the SMBD process crashes with an ACCVIO and leaves a .DMP file. Windows Explorer attempts to reconnect, the user is presented with a dialog that asks if the file should be CREATED (remember, we actually want to DELETE the file!), and the entire process terminates only after several ridiculous popups, creating multiple SAMBA$SMBD.DMP files, depending on the operation that failed (creating a new file, deleting an existing one).

Anybody care to point me to the exact place where I made a big mistake? - Or to help me find out how to avoid the ACCVIOs in SMBD?
Honored Contributor

Re: CIFS for OpenVMS / Shared (among VMS users) Directories

Contact Shilpa Krishnareddy for some CIFS security-related documentation; see the posting within the following thread:

John Gillings
Honored Contributor

Re: CIFS for OpenVMS / Shared (among VMS users) Directories


To try and get a better handle on exactly what's happening, try enabling access auditing.


Note this is a very big hammer. You will get LOTS of audits, so probably best to do it in tightly controlled conditions.

Look at the accesses from your full privilege users, and your non-privileged users. This should tell you exactly what identifiers or privileges are being used to access the files.

If you can (being mindful of the audit load), compare them with your working Pathworks/Advanced Server systems.

Regardless of how you've configured your system, ACCVIOs and/or .DMP files are a bug and need to be reported.
A crucible of informative mistakes
Steve Reece_3
Trusted Contributor

Re: CIFS for OpenVMS / Shared (among VMS users) Directories

I echo what's already been said on the crashes - they're bugs so need to be reported.

On the file access, this looks to follow the VMS model where a privileged user has access to everything.

I'm not familiar with the NET RPC GROUP ADDMEM syntax on VMS, but you may be better off looking at the VMS Guide to System Security, found in the VMS documentation set (there's a link to the documentation set off the VMS homepage at www.hp.com/go/openvms )
The System Management Utilities Reference Manual contains details of AUTHORIZE, the management utility for user accounts and identifiers. This could be good reading to use the VMS-style interface for granting your identifiers.

The present doc set is also pointed to by the url http://h71000.www7.hp.com/doc/os83_index.html

Shilpa K
Valued Contributor

Re: CIFS for OpenVMS / Shared (among VMS users) Directories

Hi Andreas,

How are the Windows domain users mapped? Do you use "idmap uid" and "idmap gid" range to automatically map them? or do you map them using other mechanisms (explicit and implicit mapping) ?

If you are not using "idmap uid" and "idmap gid" ranges, you may want to make sure that for a OpenVMS user account that is mapped to Windows account, there exists a corresponding identifier. For example, if you have an OpenVMS user account called "ANDREAS" with a UIC of [600,600], then there must be an identifier "ANDREAS" with an UIC of [600,600]. You can execute the following command to verify the identifier and the UIC:

$ mc authorize show/id

The displayed UIC must match with the UIC of the user account "ANDREAS". If the UIC does not match, please remove the identifier and add it again with the user account UIC value. If this does not solve the crash or the user access issue, please log a with HP support.

Colin Butcher
Esteemed Contributor

Re: CIFS for OpenVMS / Shared (among VMS users) Directories

I found something similar with CIFS V1.1-ECO01-PS009 on OpenVMS Alpha V8.3 (with all current patches as at 01-Dec-2009)recently - ACCVIOs and process dumps when attemping to delete or rename files.

We weren't using ACLs - just a "public" area with the share described as public in the stanza.

Prior to PS009 it was working with all PC clients having read-write access to that public share. After PS009 we see process dumps on attempting to rename or delete a file.

After applying PS009 all the "home area" shares started to work properly with the security settings being properly inherited from the upper level directories.

As the per-use home areas are more important, they chose to stay with PS009.

Unfortunately it's a secure location, so I can't get process dumps out of there (nor much else either).

At the moment I'm setting up in my lab to reproduce the problem.

Cheers, Colin (http://www.xdelta.co.uk).
Entia non sunt multiplicanda praeter necessitatem (Occam's razor).

Re: CIFS for OpenVMS / Shared (among VMS users) Directories

Thanks to all of you!

I followed Hoff's suggestion and have meanwhile received a 30 page paper from Shilpa (thanks!), which I plan to absorb during the holidays.

From my own (limited amount of) programming experience, I agree that an ACCVIO (or "segmentation fault" or "general protection fault") is never a proper way to terminate a program. I will do my best to provide useful information to investigate the causes.

John, SET AUDIT is a good idea. However, before deploying the big hammer, I want to try talking friendly. For now, I have the impression that I understand where and why access gets granted or denied. It just doesn't seem to be what I need...

Steve, thanks for the links, I have the OpenVMS documentation site bookmarked for ready and frequent access. In fact, the setup for our areas is heavily based on information from the "OpenVMS Guide to System Security", and within OpenVMS, it has been working very well.

Shilpa, thanks again for sending the doc, please allow some time for me to read it thoroughly. For your questions:

- Our users are mapped implicitly by matching the account names. We have been synchronizing VMS/U**x/Windows user names for decades, based on a central SYSUAF as a reference base (e.g., we restrict Windows user names to 12 characters).

- I plan to register individual users manually. Therefore, I am NOT using "idmap" ranges in SMB.CONF. My SYSUAF is in synch with the RIGHTSLIST file, so in AUTHORIZE, the "Value" obtained with SHOW/ID matches the UIC from SHOW/BRIEF for the same account (except for leading zeros in the /ID value).

The VTJ article mentions CIFS for OpenVMS V1.2, but I did not see a timeline. Should I search for a solution with V1.1 ECO1 PSnnn, or just wait a few days for the release of V1.2? - How would "a few days" translate into numbers? - And how much change should I expect as a consequence of switching to SECURITY=ADS, in other words: how much retesting will I need to do? (Maybe reading the article will answer one or more of these questions...)

Shilpa K
Valued Contributor

Re: CIFS for OpenVMS / Shared (among VMS users) Directories

Hi Andreas,

As you mention that the UICs of the user account and the corresponding identifier are matching, the SMBD crash could be due to another reason. May be you want to log a call with HP Support...

Meanwhile, could you please execute the following command and post the crash call chain:

$ analyze/crash samba$smbd.dmp
SDA> show call/summ

By default, the dump files should be in samba$root:[var.cores.smbd]. But you may want to check if they are getting created in another directory.

The "security=ADS" and "security=DOMAIN" mode applies only to the authentication of the user and not to the file security.

As per file security, it is similar in CIFS V1.1 ECO1 with PS009 patch set and CIFS V1.2. After you upgrade to CIFS V1.2, you need not have to separately test for File Security again.

For the SMBD crash, suggest you to log a call for further investigation. Atleast until CIFS V1.2 is released, the fixes for the problems reported are made available for CIFS V1.1 ECO1 (based on the latest patch set). CIFS V1.2 is expected to be released during Q2 of 2010.

Shilpa K
Valued Contributor

Re: CIFS for OpenVMS / Shared (among VMS users) Directories

Hi Andreas,

You have specified the share path as "path = /area$%S/%S". I think you can workaround the SMBD crash problem by specifying the path in VMS path format as:

path = area$%S:[%S]

You may want to log a call to report the SMBD crash problem when the path similar to the above is specified in Unix path format.


Re: CIFS for OpenVMS / Shared (among VMS users) Directories

Holidays and some additional responsibilities introduced with the new year kept me away from this issue, sorry for the delay in my response!

The document that Hoff recommended was my lecture for the holidays, and I want to join him in recommending the article: it compiles information from different sources in a single place and relates the pieces to each other, so it's an excellent one-stop source. Some of the points assigned for Shilpa's responses are meant to be one way of saying "thank you" for this good article.

After reading the article, I believe that we do what is described at the bottom of page 14 / top of page 15, so I think our concept is valid and even had been considered by the developers.

The information from the dump file, as requested by Shilpa K on Dec 23, is attached.

Shilpa's hint from his latest post (using VMS syntax instead of Unix syntax in SMB.CONF) gives an improvement in that the SMBD process no longer crashes with a .DMP. Instead, a user who is member of a domain global group that is (through nesting in a local group associated with rights identifier FOO_R in my test share) allowed read-only access can now create files and change their content, the user only cannot rename nor delete these files.

This is slightly better in that the process survives now, but from a security viewpoint, it is certainly not what I need.

Maybe there is another workaround?
Shilpa K
Valued Contributor

Re: CIFS for OpenVMS / Shared (among VMS users) Directories

Hi Andreas,

Could you please check the privileges for the OpenVMS user account that is mapped to the Windows user? By the Windows user, I mean the user who is able to create file in the directory but cannot delete/rename it. I wonder if the mapped OpenVMS user account has a SYSPRV.


Re: CIFS for OpenVMS / Shared (among VMS users) Directories

Hello Shilpa,

Now, this is most embarrassing: yes, the VMS user account had /DEFPRIV=SYSPRV! After removing this (and leaving only /PRIV=SYSPRV on), the user can still do management tasks, but SMBD perfectly obeys the rules set forth in ACLs and SMB.CONF!

Sorry for bugging you with this last one, which was clearly my fault. Time to remember checking the VMS account when CIFS surprises me, time to memorize that there ARE differences between Advanced Server and CIFS for OpenVMS!

Thanks a lot again for pushing me to learn my lessons! ;-)