[prev in list] [next in list] [prev in thread] [next in thread] 

List:       racf-l
Subject:    Re: BPX.DEFAULT.USER vs RESTRICTED.FILESYS.ACCESS
From:       Per <per_bonthelius () YAHOO ! CO ! UK>
Date:       2013-01-29 16:59:22
Message-ID: 63D3D4DF-2A27-4C24-A990-6CC6F5B18692 () yahoo ! co ! uk
[Download RAW message or body]

Thanks Hayim,

That clarifies this matter.

Sent from my iPhone, so please excuse any spelling mistakes.

On 29 Jan 2013, at 16:10, "Sokolsky, Hayim Z." <hsokolsky@DTCC.COM> wrote:

> There are two separate events here:
> 
> 1. User is "dubbed" (becomes a Unix user).
> This involves FACILITY BPX.DEFAULT.USER as a default UID & GID setup, when the user \
> doesn't have either a UID or a GID.  Two important points: (1) this is only \
> supported up to z/OS 1.13, and (2) it is not affected by the user being RESTRICTED. \
>  2. User attempts to reference a file in the Unix File System (HFS or zFS)
> If the file is owned by the user - user's UID owns the file - even if it was via \
> BPX.DEFAULT.USER, then the user has access. If the file is owned by the user's \
> group - group's GID owns the file - even if it was via BPX.DEFAULT.USER, then the \
> user has access. 
> If the user's UID or GID is not the user or group in the files FSP, then the \
> "other" value comes into play. If the user is RESTRICTED, and \
> RESTRICTED.FILESYS.ACCESS is defined (and the user is not permitted directly or via \
> a group), then access is denied. 
> 
> Hayim
> 
> Hayim Sokolsky
> Manager, Mainframe Security Architecture
> DTCC Technology Risk Management
> 18301 Bermuda Green Drive, MS 1-CIS
> Tampa FL 33647-1760
> +1 (813) 470-2177
> 
> Classification:  DTCC Non-Confidential (WHITE)
> 
> The views I have expressed in this email are my own personal views, and are not \
> endorsed or supported by, and do not necessarily express or reflect, the views, \
> positions or strategies of my employer. 
> 
> > -----Original Message-----
> > From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf Of
> > Per
> > Sent: Tuesday, January 29, 2013 08:50
> > To: RACF-L@LISTSERV.UGA.EDU
> > Subject: Re: BPX.DEFAULT.USER vs RESTRICTED.FILESYS.ACCESS
> > 
> > Hi Hayim,
> > 
> > I am not sure if I have understood what you mean by this.
> > Yes the RESTRICTED.FILESYS.ACCESS is set up, to ensure that users
> > RESTRICTED in RACF, cannot get default, access to world permits (UACC).
> > But if they don't have a OMVS segment, BPX.DEFAULT.USER gives them
> > access. By activating the RESTRICTED.FILESSYS profile will the access get
> > currently get through BPX be lost. I.e which profs takes prescedent?
> > Sent from my iPhone, so please excuse any spelling mistakes.
> > 
> > On 29 Jan 2013, at 12:43, "Sokolsky, Hayim Z." <hsokolsky@DTCC.COM>
> > wrote:
> > 
> > > Per,
> > > 
> > > My understanding is that RESTRICTED.FILESYS.ACCESS blocks access that
> > was obtained by "Other" - which is the USS equivalent of UACC. If the default
> > UID or GID that these users are assigned owne the file, they will still have
> > access. This is no different if than if the two users and their groups have
> > OMVS segments.
> > > 
> > > 
> > > Hayim
> > > 
> > > Hayim Sokolsky
> > > Manager, Mainframe Security Architecture
> > > DTCC Technology Risk Management
> > > 18301 Bermuda Green Drive, MS 1-CIS
> > > Tampa FL 33647-1760
> > > +1 (813) 470-2177
> > > 
> > > Classification:  DTCC Non-Confidential (WHITE)
> > > 
> > > The views I have expressed in this email are my own personal views, and
> > are not endorsed or supported by, and do not necessarily express or reflect,
> > the views, positions or strategies of my employer.
> > > 
> > > > -----Original Message-----
> > > > From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On
> > Behalf
> > > > Of Per
> > > > Sent: Tuesday, January 29, 2013 07:10
> > > > To: RACF-L@LISTSERV.UGA.EDU
> > > > Subject: BPX.DEFAULT.USER vs RESTRICTED.FILESYS.ACCESS
> > > > 
> > > > Hi we are using RESTRICTED.FILESYS.ACCESS to enable the RESTRICTED
> > > > Attribute in Unix. We have 2 users that are RESTRICTED and do not
> > > > have a OMVS segment, which get their access through BPX.DEFAULT.
> > USER
> > > > If we Activate RESTRICTED.FILESYS.ACCESS will they lose this access?
> > > > 
> > > > Best regards,
> > > > 
> > > > Per
> > > > 
> > > > Sent from my iPhone, so please excuse any spelling mistakes.
> > > > 
> > > > On 29 Jan 2013, at 06:53, D E Engelbrecht
> > > > <elardus.engelbrecht@SITA.CO.ZA>
> > > > wrote:
> > > > 
> > > > > Bob Bridges wrote:
> > > > > > Over the past two weeks I've looked into mysteries I never dreamt
> > > > > > of
> > > > > before: ICHRRNG, ICHRRCDE, ICHRDSNT and others.  In the last 24
> > > > > hours I've spent time in the SysProg manual, which until now was ...
> > > > > well, a closed book to me.  Guess I have a lot more to learn, but I
> > > > > see no reason to back out now.
> > > > > 
> > > > > RACF is FULL of (dark and murky) mysteries!!! ;-D
> > > > > 
> > > > > Just ask again and if you succeeds in your quest, please tell us.
> > > > > 
> > > > > Good luck and all of the very best for you!
> > > > > 
> > > > > Groete / Greetings
> > > > > Elardus Engelbrecht
> > <BR>______________________________________________________
> > _______
> > > <FONT size=2><BR>
> > > DTCC DISCLAIMER: This email and any files transmitted with it are
> > > confidential and intended solely for the use of the individual or
> > > entity to whom they are addressed. If you have received this email in
> > > error, please notify us immediately and delete the email and any
> > > attachments from your system. The recipient should check this email
> > > and any attachments for the presence of viruses.  The company accepts
> > > no liability for any damage caused by any virus transmitted by this
> > > email.</FONT>
> <BR>_____________________________________________________________
> <FONT size=2><BR>
> DTCC DISCLAIMER: This email and any files transmitted with it are
> confidential and intended solely for the use of the individual or
> entity to whom they are addressed. If you have received this email
> in error, please notify us immediately and delete the email and any
> attachments from your system. The recipient should check this email
> and any attachments for the presence of viruses.  The company
> accepts no liability for any damage caused by any virus transmitted
> by this email.</FONT>


[prev in list] [next in list] [prev in thread] [next in thread]