Re: AW: Re: permissions to /bin/sh

See the write up on _BPX_SHAREAS in BPX1SPN and how _BPX_SHAREAS=YES/MUST affects local spawn with the sticky bit is set. Kirk Wolf Dovetailed Technologies http://dovetail.com On Fri, Aug 25, 2017 at 12:52 AM, Peter Hunkeler wrote: > >on z/OS the sticky bit on an executable file affects how a

AW: Re: AW: Re: permissions to /bin/sh

>on z/OS the sticky bit on an executable file affects how a spawn() and >_BPX_SHAREAS works. It mainly affects where the loader starts looking for the program to be loaded, namely LPA. Its a performance thing in the first place. Then, for some reason unknown to me, IBM had to decide that such

Re: permissions to /bin/sh

> On Aug 24, 2017, at 11:30 AM, Paul Gilmartin > <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > On Thu, 24 Aug 2017 12:17:29 -0400, Tony Harminc wrote: >> >> No - never. AMASPZAP (IMASPZAP before MVS, i.e. before 1972, and before the >> notion of APF authorization) was always subjec

Re: permissions to /bin/sh

> On Aug 24, 2017, at 11:17 AM, Tony Harminc > wrote: > > On 24 August 2017 at 04:41, R.S. > wrote: > >> W dniu 2017-08-23 o 18:25, Karl S Huf pisze: >> >>> NTAC:3NS-20 >>> >>> Good question. Reminds me of the age-old Auditor 10

Re: permissions to /bin/sh

Sent from my iPhone Sorry for any grammar problems > On Aug 24, 2017, at 16:54, Walt Farrell wrote: > >> On Thu, 24 Aug 2017 16:06:26 -0500, Paul Gilmartin >> wrote: >> >>> On Thu, 24 Aug 2017 15:22:30 -0500, Walt Farrell wrote: >>> On Thu, 24 Aug 2017 11:30:26 -0500, Paul Gilmartin w

Re: permissions to /bin/sh

On Thu, 24 Aug 2017 16:06:26 -0500, Paul Gilmartin wrote: >On Thu, 24 Aug 2017 15:22:30 -0500, Walt Farrell wrote: > >>On Thu, 24 Aug 2017 11:30:26 -0500, Paul Gilmartin wrote: >> >>>Is AMASPZAP linked AC=1? It would seem that there's no need for that >>>nowadays: >>>AC=0 with suitable data set

Re: permissions to /bin/sh

On Thu, 24 Aug 2017 15:22:30 -0500, Walt Farrell wrote: >On Thu, 24 Aug 2017 11:30:26 -0500, Paul Gilmartin wrote: > >>Is AMASPZAP linked AC=1? It would seem that there's no need for that >>nowadays: >>AC=0 with suitable data set and programmer profiles should suffice. > >Even if what you need t

Re: permissions to /bin/sh

On Thu, 24 Aug 2017 11:30:26 -0500, Paul Gilmartin wrote: >On Thu, 24 Aug 2017 12:17:29 -0400, Tony Harminc wrote: >> >>No - never. AMASPZAP (IMASPZAP before MVS, i.e. before 1972, and before the >>notion of APF authorization) was always subject to dataset protection (via >>passwords, long before

Re: permissions to /bin/sh

On Thu, 24 Aug 2017 12:17:29 -0400, Tony Harminc wrote: > >No - never. AMASPZAP (IMASPZAP before MVS, i.e. before 1972, and before the >notion of APF authorization) was always subject to dataset protection (via >passwords, long before RACF), ... > Is AMASPZAP linked AC=1? It would seem that there

Re: permissions to /bin/sh

On 24 August 2017 at 04:41, R.S. wrote: > W dniu 2017-08-23 o 18:25, Karl S Huf pisze: > >> NTAC:3NS-20 >> >> Good question. Reminds me of the age-old Auditor 101 question: "What do >> you do to restrict AMASPZAP?" >> Explaining that it's just a tool like any other and that the real issue >> is

Re: AW: Re: permissions to /bin/sh

on z/OS the sticky bit on an executable file affects how a spawn() and _BPX_SHAREAS works. Its kind of a hack (mess). Kirk Wolf Dovetailed Technologies http://dovetail.com On Thu, Aug 24, 2017 at 12:06 AM, Peter Hunkeler wrote: > >1. The problem with IDz was real and solved by change the permi

Re: permissions to /bin/sh

W dniu 2017-08-23 o 18:25, Karl S Huf pisze: NTAC:3NS-20 Good question. Reminds me of the age-old Auditor 101 question: "What do you do to restrict AMASPZAP?" Explaining that it's just a tool like any other and that the real issue is properly securing the entities it might update is the real so

AW: Re: AW: Re: permissions to /bin/sh

>1. The problem with IDz was real and solved by change the permissions. To me this is not a solution rather a circumvention to the real problem. No process should recognize the difference in calling, i.e. fork()/exec() or spawn(), a UNIX binary having or not having the sticky bit set. If iDZ

Re: permissions to /bin/sh

eaf ears. They believed there was something magical about Zap. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Paul Gilmartin > Sent: Tuesday, August 22, 2017 11:15 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXT]

Re: AW: Re: permissions to /bin/sh

W dniu 2017-08-23 o 12:52, Peter Hunkeler pisze: A little bit of explanations. I asked the question, because I found discrepancy in the permissions. Who, how, when, and why changed the permissions - I don't know, that's another story. However the system seemed to work properly with r-x on /bin/

AW: Re: permissions to /bin/sh

>A little bit of explanations. I asked the question, because I found discrepancy in the permissions. Who, how, when, and why changed the permissions - I don't know, that's another story. However the system seemed to work properly with r-x on /bin/sh. The problem occured during installation of some

Re: permissions to /bin/sh

W dniu 2017-08-22 o 16:30, Robert Hansel pisze: Itschak and Radoslaw, I believe the permissions for /bin/sh should be 1755, displayed as rwxr-xr-t. Note the 1 for the attribute, displayed as 't', activates the Sticky Bit. This causes Unix to execute an MVS program by the name of SH instead of

Re: permissions to /bin/sh

On Wed, 23 Aug 2017 07:08:39 +0300, ITschak Mugzach wrote: > >There are users associated with tasks. Disallowing shell is much like tbe >protected attribute in racf. > Shouldn't the better practice be to protect the resources rather than restrict the tool? >בתאריך 22 באוג 2017 23:00,‏ "Paul Gilm

Re: permissions to /bin/sh

Gil, There are users associated with tasks. Disallowing shell is much like tbe protected attribute in racf. ITschak בתאריך 22 באוג 2017 23:00,‏ "Paul Gilmartin" < 000433f07816-dmarc-requ...@listserv.ua.edu> כתב: > On Mon, 21 Aug 2017 12:34:34 +0300, ITschak Mugzach wrote: > > >0755 or less

Re: permissions to /bin/sh

On Mon, 21 Aug 2017 12:34:34 +0300, ITschak Mugzach wrote: >0755 or less > Why would *anyone* *ever* choose to restrict the permissions of sh!? >בתאריך 21 באוג 2017 11:12,‏ "R.S." כתב: > >> What is default (suggested, typical) permission to /bin/sh ? >> Of course I mean z/OS UNIX (2.2 if it make

AW: Re: permissions to /bin/sh

>Admittedly, I have not tried turning off the Sticky Bit in order to execute >file sh in the /bin directory, so perhaps it would still function properly. Sure it will, at least as long as the file /bin/sh is the real shell binary, aka load module. It's a performance penalty, only, since the shel

Re: permissions to /bin/sh

A.EDU Subject: Re: permissions to /bin/sh **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Itschak and Radoslaw, I believe the permissions for /bin/sh should be 1755, displayed as rwxr-xr-t. Note the 1 for the attribute, displayed

Re: permissions to /bin/sh

21 Aug 2017 12:34:34 +0300 From:ITschak Mugzach Subject: Re: permissions to /bin/sh 0755 or less בתאריך 21 באוג 2017 11:12,‏ "R.S." כתב: > What is default (suggested, typical) permission to /bin/sh ? > Of course I mean z/OS UNIX (2.2 if it makes a difference) > Is it rwxr

AW: Re: permissions to /bin/sh

1755, the shell has the sticky bit set by IBM's installation default. -- Peter Hunkeler Von: ITschak Mugzach An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: permissions to /bin/sh Datum: 21.08.17, 11:34 0755 or less בתאריך 21 באוג 2017 11:12,‏ "R.S." כת

Re: permissions to /bin/sh

0755 or less בתאריך 21 באוג 2017 11:12,‏ "R.S." כתב: > What is default (suggested, typical) permission to /bin/sh ? > Of course I mean z/OS UNIX (2.2 if it makes a difference) > Is it rwxr-xr-t ? > > -- > Radoslaw Skorupka > Lodz, Poland > > > > >