System security

[Sumant M Kumar]

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

[Steven Schweda]

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]

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 · Accepted solution]

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.

[Robert Gezelter]

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]

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]

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.

[Sumant M Kumar]

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]

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.

[Sumant M Kumar]

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