cancel
Showing results for 
Search instead for 
Did you mean: 

FDL Security

 
SOLVED
Go to solution
vmsserbo
Super Advisor

FDL Security

I need to investigate the current ownership and protection for files in the PROD_FDL directory on all of our 40 nodes.

I need to recommend a security standard that will work around the country while protecting the files at the highest possible level.

Has anyone done this on their sites?

For instance, if World does not have access to any FDL files on some of the nodes, I can guess that World probably does not need any access, and recommend that as a standard.

Is there a better command that I can use besides dir/sec?

This is what I get as an example

dir/sec Nodename::prod_fdl:
SYSTBMIS.FDL;5 [500,7777] (RWED,RWED,RWE,RWE)


Any ideas?

Thanks!


8 REPLIES 8
Steven Schweda
Honored Contributor
Solution

Re: FDL Security

> [...] I can guess [...]

It might make more sense to start by trying
to understand the access requirements for
these files, rather than assuming that the
existing protections actually make any sense.
(For example, why would W:RWE be better than,
say, W:RW?) You could save a lot of work by
guessing that everything's ok now, too, if
guessing is good enough.

> Is there a better command that I can use
> besides dir/sec?

I believe that you can get the owner-group
data from F$FILE_ATTRIBUTES. I don't know of
a handy way to get the security data.
Hein van den Heuvel
Honored Contributor

Re: FDL Security

If the FDL files are indeed what the names imply then they are RMS File Description Files, used for production file re-creates or convert.

So they need to be readable by whatever username executes those creates/converts, and in that sense might as well have the same protection as the data files to be created

There is no valuable data - data in them, just meta data, so world read is fine, unless you feel the need to control idle curiousity.

World write is rather bad for those files, not because they can directly trash production data, but because of 'denial of service' potential. Anyone mucking with those files can leave a boobytrap for some future convert which may be months (years) away and then create an unusable data file.

You could argue that only development and a DBA style user can/should have write access to FDL files, NOT the operators / production support users using them.

Typically I would hope operators / production support is smart enough to be trusted with FDL and even allowed to make tuning changes (allocation, extent, bucketsize).

Cheers,
Hein van den Heuvel
HvdH Performance Consulting
vmsserbo
Super Advisor

Re: FDL Security

Thanks for the input I do agree with what your saying.

The way it stands now, most fdl protectons
are set like this

(RWED,RWED,RWE,RW)

I think I am going to recommend the following

(RWED,RWED,RWE,R)

Should the Group be able to have the "D" delete permission?

Your thoughts?

Thanks again!
vmsserbo
Super Advisor

Re: FDL Security

Thanks for all you help

I will follow the same protections scheme for our .fdl files as we have with our .dat files

(RWED,RWED,RWED,R)

Thanks and Happy New Year!
Jim_McKinney
Honored Contributor

Re: FDL Security

> Should the Group be able to have the "D" delete permission?


Only you can answer this. Who is in the UIC group besides the owner? Do you want these other users to be able to delete these FDL files? If not, then you'll probably want to remove that potential.