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

System security

 
SOLVED
Go to solution
Sumant M Kumar
Frequent Advisor

System security

Hi,

I need to set delete permission for test user who belongs to group [200,*].There are four test users in [200,*] group test,test1,test2 & test3.There is file SYS$SYSROOT:[SYSMGR]apps.com and permission is as below
$ dir/sec SYS$SYSROOT:[SYSMGR]apps.com
Directory SYS$SYSROOT:[SYSMGR]
apps.com;1 [SYSTEM] (RWED,RWED,RWED,RWE)

Now i need to set Delete permission for the user test but not for all the group so for that i used ACL but still i am unable to delete apps.com file.

$set security/acl=(identifier=[test],access=read+write+execute+delete] apps.com

When i logged in as test user and tried to delete the file its throwing errro "insufficient privilege".

Could you please suggest me if i need to use any ACL qualifier.

Regards,
Sumant
14 REPLIES
Steven Schweda
Honored Contributor

Re: System security

It might help if we could see the output from
a new "dire /secu" command. Also, the actual
"delete" command (and its actual error
message).
Steven Schweda
Honored Contributor

Re: System security

One other likely problem. As the HELP says:

DELETE

file

Deletes one or more files from a mass storage disk volume.

Requires delete (D) access to the file and write (W) access to
the parent directory. If the target file is itself a directory,
the directory must be empty.
[...]


Write access to the file's parent directory?
Jon Pinkley
Honored Contributor
Solution

Re: System security

To delete a file the process must have delete access to the file (in your case APPS.COM) and also write access to the directory that the file is in, in your case sys$sysroot:[000000]sysmgr.dir

If what you are showing us is actual output, that file will be

sys$specifiec:[000000]sysmgr.dir

or to determine absolute path:

$ TOPSYS = F$TRNLNM("SYS$TOPSYS")
$ DIR/SEC SYS$SYSDEVICE:['TOPSYS']SYSMGR.DIR

I would recommend moving APPS.COM out of SYS$MANAGER. In general it is best not to hand out write access to this directory.

See the guide to system security - chapter 8.
it depends
Robert Gezelter
Honored Contributor

Re: System security

Sumant,

As has been noted, access to the directory is required so that the file's directory entry can be removed.

Please note that this is a good reason to move such files out of the SYS$SYSROOT:[SYSMGR] directory. Giving a user sufficient access to manipulate this file ALSO gives them sufficient privilege to disrupt that directory.

Since that directory is critical to system operation, I would strongly counsel movbing that file to a different directory. This prevents accidental collateral damage.

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

Hoff
Honored Contributor

Re: System security

You will want to consider the use an OpenVMS resource identifier here in preference to the current UIC-based approach being discussed; resource identifiers are more flexible and more manageable, and can easily be configured (for instance) across UIC groups.

Here's a short write-up on how to set up a resource identifier and the related security and (if needed) disk quotas for a shared project directory:

http://labs.hoffmanlabs.com/node/1450

This example shows delete access for the resource identifier. In your specific case, you'd likely look to remove that access from both the default protection ACE and the protection ACE, and to add a parallel default protection ACE and protection ACE for the specific user (or probably better, for a user with a specific identifier) that allowed delete access. These two ACEs almost exactly parallel the ACEs shown in the cited example, though would be for, say, FOO_MANAGE identifier.

OpenVMS resource identifiers differ from standard security identifiers in the assignment of ownership and the ability to associate (if needed) a disk quota entry with identifier.
John Gillings
Honored Contributor

Re: System security

Sumant,

To diagnose any file manipulation command which fails with "insufficient privilege",
open a new window and enable it as a security operator console (needs OPER and SECURITY privilege)

$ REPLY/ENABLE=SECURITY

Now enable audit alarms of file access failures:

(needs SECURITY privilege)

$ SET AUDIT/ALARM=ENABLE=FILE=FAIL=ALL

Now repeat your failing command.

This should generate an audit alarm telling you exactly which file is failing, what type of access has been requested, and why it's failing. It's often not the file you think it is.
A crucible of informative mistakes
Sumant M Kumar
Frequent Advisor

Re: System security

Thanks for your all suggestions now i am able to delete the file as a test user.I set the (g:rwed,w:re) permission on sysmgr.dir directory and also set the acl for the test user.
Directory SYS$SYSROOT:[SYSMGR]
Apps.com;1 [SYSTEM] (RWED,RWED,RWED,RWE)
(IDENTIFIER=[TEST],ACCESS=READ+WRITE+EXECUTE+DELETE)

Regards,
Sumant


Joseph Huber_1
Honored Contributor

Re: System security

Just a side note:
Apps.com;1 [SYSTEM] (RWED,RWED,RWED,RWE)
has WORLD WRITE access!
I hope this is not the default protection of the owner SYSTEM !
Check with SHOW PROTECTION.
http://www.mpp.mpg.de/~huber
Sumant M Kumar
Frequent Advisor

Re: System security

Thanks Joseph for letting me know about that.Yes you are right now i have removed the write permission from world.

$ dir apps.com/sec
Directory SYS$SYSROOT:[SYSMGR]
APPS.COM;1 [SYSTEM] (RWED,RWED,RWED,RE)
(IDENTIFIER=[TEST],ACCESS=READ+WRITE+EXECUTE+DELETE)



Regards,
Sumant
Wim Van den Wyngaert
Honored Contributor

Re: System security

Group users still have rwed. You said 1 user only so the d should go too.

Wim
Wim
Jan van den Ende
Honored Contributor

Re: System security

Sumant,

please, PLEASE read (and follow) the advise by Bob G (also hinted by Jon P) about MOVING ANY NON-OS stuff AWAY from [SYSMGR] (and all other SYS$SYSROOT directories) !!!

I have seen DISASTROUS thing happen by it!!

success.

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Hoff
Honored Contributor

Re: System security

Yes, stay clear of SYS$SYSROOT.

It's a certainty that the SYS$SYSROOT searchlist does not work as might be expected. There are all manner of corner cases lurking within searchlists that can trip up even the most experienced of OpenVMS programmers. Files aren't necessarily where you might expect, and multiple directories must be created or you can get errors you might not expect.

Use your own top-level directory.
Peter Zeiszler
Trusted Contributor

Re: System security

You really really want to move user stuff out of the main system directory. One wrong slip up and you may end up rebuilding a broken system.

Do you have another disk that it can be moved to? Show dev D
Sumant M Kumar
Frequent Advisor

Re: System security

Hello Guru's,

I have moved the file from system disk to data disk(DKA100) and revoked the default permission on dka5:[sys0]sysmgr.dir

Now i have a better idea about ACL and setting permissions on dir/users & files and impact if i set wrongly on system directories.Thanks a lot for your valuable time and guidance.

Regards,
Sumant