IBM Mainframe Forum

Hi all,

In z/os V1R8 I have a user with uid=1020. I want to prevent this user(and similar users) to access the ROOT directory, when he enter omvs

segment (by "tso ishell" command). How I can do this?


best regards
mehrdad rastgar,
Behsazan Mellat co.,
Tehran.IRAN

When you say "prevent ... access", are you talking about prventing reads, writes, or executes, or all of the above? And do these users share a Unix group with ROOT? Change the permissions on the ROOT directory appropriately based on the answers to these questions.

Hi,

I mean "banding Anonymous access to omvs segment from RACF".
Is there anyway?

Since I have no idea what this means, I have no ideas:

"banding Anonymous access to omvs segment from RACF"

I do think you need to spend several days reading some basic Unix manuals to understand access controls in Unix, since Unix System Services access in z/OS works mostly on the Unix access controls principles.

Further, your first post provided a specific UID, yet your last post mentions "Anonymous access" - perhaps you need to decide what you want, first? Anonymous access and a specific UID are complete opposites. Plus, anonymous access is usually applied to FTP sessions and you've not mentioned anything yet about FTP.

Basically, your questions are so vague and subject to interpretation so much that they cannot be answered as you've posted them.

Maybe he meant "banning" instead of "banding"?

banning = preventing entry

banding = wrapping something in a band of material, like a bandage on a wound, or one of those straps you see on stacks of money.

Hi,

In most of the shops Access to Root directory are not allowed for a normal users but some of the Product based path would be provided if only when it is required(Like DB2 or CICS or Java). If you feel the user or the permission levels have changed then you can just restrict the level of access based on the path.

Any particular path you want to restrict ? Reading a Unix security service guides or any manual commands would give you more idea to plan the security enforcement.

Jaggz

Hello,

And unless you Are the Security Support, you should set up this with the Security Admins.

If you want to explicitly deny a given ID you can use the setfacl command (man setfacl for all the manpage goodness that it has to offer). This is the file level ACL controls. So not only do you have the POSIX ownership control of Read Write eXecute for the User (that owns the file), the Group (that owns the file) and Other (everybody else on the system) you have a more granular level similar to ACL entries on a RACF profile where you can include and exclude other IDs or groups explicitly like you would with a PERMIT. In general I find it a bit absurd that folks build a new RACF group or go around changing OWNERSHIP to protect a specific folder in some cases when ACCESS CONTROL is separate from OWNERSHIP control (ie; this is like changing the owner of a profile to a new group to make the access work instead of adding new permits).

A quick example of the commands use:

First line allows the user ABC123 full read/write/execute access on existing files in the folder.
Second line allows the user ABC123 full read/write/execute access on files that will be created in the future.
setfacl -m user:ABC123:rwx /root/*
setfacl -m fdefault:user:ABC123:rwx /root/

Not sure if you meant root (/) or root (/root) directory by the way... in general the /root directory (and all individual home directories) should be chmod'd 700' and chown'd user:user. If you are going to break with this convention to "make some product work" you may have some other unintended consequences. In general, assuming somebody hasn't gone and chmod 777'd the /root or / directory per some installation guide you should already have adequate access in place since the user likely wouldn't own the directory or be in the group that owns the directory and the "other" access which covers them would be non-existent.