changing fdl file protection

[Steve ward_3]

What is the exact command to change FDL file protections so that all users can be able to add/remove FDL files

[Wim Van den Wyngaert]

1. Give write access to world on the parent directory. Set file/prot=(w:rwe) x.dir

2. Set an acl on the parent directory to create all future files without protection.
set sec x.dir/acl=(default,s:rwed,o:rwed,g:rwed,w:rwed)

3. Change all fdl files to get that protection set file *.fdl/prot=(s:rwed,o:rwed,g:rwed,w:rwed)

Wim

[Wim Van den Wyngaert]

This opens of course the directory for all files, not only *.fdl.

Wim

[Hein van den Heuvel]

As Wim replies, FDL files are just (text) files and have not special protection rules.

FDL files may have an OWNER and PROTECTION clause in them for the target file, but that is often mre a nuisance than help. Just set the protection after the target file create, if needed at all.

It is somewhat odd to allow all uses to add and delete FDL files IF those are also used for production files, as it is all too easy to put something bad in place, or remove something good, impacting production.

If you need more help than Wim's replies offer, then please be sure to explain a little better what root problem you are trying to solve, and how those FDL's will be used. How come 'all users' even know how to create FDL files? That's not typical, not even for a development shop.

Cheers,
Hein van den Heuvel

[Wim Van den Wyngaert]

BTW : the simplest solution is to give all users all privs.

Wim

[Robert Gezelter]

Steve,

Permitting all users to add/remove FDL files to a master location is a dangerous practice. A single incorrect keystroke can cause major mayhem and disruption, all without any intent to do harm.

My personal preferences depend upon precisely what problem is being addressed. One common solution for testing is to use a consistent logical name to access the FDL files in your programs and command procedures, thus permitting a fine degree of control of where the FDL file is actually retrieved from (which can provide for a list of defaults). Just such an approach was described in " Inheritance Based Environments in Stand-alone OpenVMS Systems and OpenVMS Clusters", published in the OpenVMS Technical Journal, Volume 3, February 2004 (reprints available via http://www.rlgsc.com/publications/vmstechjournal/inheritance.html ).

As to the group and global libraries, my normal recommendation is to limit add/delete access, possibly by having the library directory owned by an Identifier, with the Identifier granted to those users authorized to make more global updates.

While such a scheme is a bit of work, it creates accountability for changes.

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

Look up "resource identifier" in the security manual and around the Internet for details on this; this approach avoids needing to set protections, deal with protections in the FDL files, nor to deal with the file ownership.

Basically, you configure the shared files off to the ownership of the identifier, and grant the identifier to the folks that need to share access.

This also avoids granting privileges all around.