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

[Kirk Wolf]

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 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 modules must not be
> loaded as local process. I guess it's an system integrity issue. Therefore
> it affects spawn().
>
>
> >Its kind of a hack (mess).
>
>
> In what sense do you think it is a hack? I agree its a mess, in that is
> inhibits a locally spawned shell.
>
>
> --
> Peter Hunkeler
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Peter Hunkeler]

>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 modules must not be loaded as local 
process. I guess it's an system integrity issue. Therefore it affects spawn().


>Its kind of a hack (mess).


In what sense do you think it is a hack? I agree its a mess, in that is 
inhibits a locally spawned shell.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Kirk Wolf]

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 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 is having problems with the shell when the sticky bit is not set,
> there is something wrong in the iDZ code. It is not using the proper calls
> / funtions() in some way or the other.
>
>
> --
> Peter Hunkeler
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Peter Hunkeler]

 >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 is having problems with the shell when the sticky bit is not set, there 
is something wrong in the iDZ code. It is not using the proper calls / 
funtions() in some way or the other.


--
Peter Hunkeler


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[R.S.]

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/sh. The problem occured during installation of some IBM product,
part of IDz (former RDz - Rational Developer for System z). Change to
r-t fixed the problem.


Not sure what the problem was that you encountered. However, it seems to me 
that some part of your installation had not been done properly or completely. 
The shell is installed into LPA *and* into the /bin path of your version root 
file system. without the sticky bit, the version from the /bin directory is 
always used. The LPA version is not relevant. With the sticky bit, the LPA 
version is always used, and the version  in /bin is not relevant. Except when 
the shell is not found in LPA, then the loader goes back and loads it from the 
/bin directory.


I cannot say how a version discrepancy could cause troubles, but the same issue 
might exist with other sticky bit UNIX binaries, and the corresponding load 
module.


As a side note: Other permission r-x is exactly the same as r-t from a 
permission point of view. The lower case t means x permission and sticky bit is 
set. Its kind of as overpunching on punch cards. The sticky bit is show in the 
same position as the execute permission. Sticky and no execute permission is 
shown as T, sticky and execute permission is shown as t. No sticky bit but 
execute permission is shown as x.


Similarly, the Set-UID-bit and Set-Gid-bit are "overpunched" over the x 
position in the Owner, and Groups parts, resp. Shown as S or s, depending on whether 
execute permission is also present or not.





Peter,
1. The problem with IDz was real and solved by change the permissions. 
The system originally was created properly, including permissions to 
/bin/sh - that's I'm sure, because I have an access to the "source 
image" of cloned system having the problem.


2. Do not take "permissions" word so literally. We're aware the "t" is 
just kind of brevity, an equivalent of "x + sticky". It's better visible 
in octal form, but 4-digit. From the other hand octal "5" is not 
intuitive as "r-x".



Regards
--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: permissions to /bin/sh

[Peter Hunkeler]

>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 IBM product,
part of IDz (former RDz - Rational Developer for System z). Change to
r-t fixed the problem.


Not sure what the problem was that you encountered. However, it seems to me 
that some part of your installation had not been done properly or completely. 
The shell is installed into LPA *and* into the /bin path of your version root 
file system. without the sticky bit, the version from the /bin directory is 
always used. The LPA version is not relevant. With the sticky bit, the LPA 
version is always used, and the version  in /bin is not relevant. Except when 
the shell is not found in LPA, then the loader goes back and loads it from the 
/bin directory.


I cannot say how a version discrepancy could cause troubles, but the same issue 
might exist with other sticky bit UNIX binaries, and the corresponding load 
module.


As a side note: Other permission r-x is exactly the same as r-t from a 
permission point of view. The lower case t means x permission and sticky bit is 
set. Its kind of as overpunching on punch cards. The sticky bit is show in the 
same position as the execute permission. Sticky and no execute permission is 
shown as T, sticky and execute permission is shown as t. No sticky bit but 
execute permission is shown as x.


Similarly, the Set-UID-bit and Set-Gid-bit are "overpunched" over the x 
position in the Owner, and Groups parts, resp. Shown as S or s, depending on 
whether execute permission is also present or not.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: permissions to /bin/sh

[Peter Hunkeler]

>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 shell program is 
loaded each time it is called.

>Is there a compelling reason to turn off the Sticky Bit?c

Don't know if it is compelling, but the sticky bit inhibits a local spawn of 
the shell. So when it is cleared, it should be possible to run the shell via 
BPXBATSL, which starts the child process via local spawn.
-- Peter Hunkeler







--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: permissions to /bin/sh

[Peter Hunkeler]

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."  כתב: 
 
> 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 
> 
> 
> 
> 
> == 
> 
> 
>-- 
> Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
> przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być 
> jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś 
> adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej 
> przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, 
> rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie 
> zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, 
> prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale 
> usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub 
> zapisane na dysku. 
> 
> This e-mail may contain legally privileged information of the Bank and is 
> intended solely for business use of the addressee. This e-mail may only be 
> received by the addressee and may not be disclosed to any third parties. If 
> you are not the intended addressee of this e-mail or the employee 
> authorized to forward it to the addressee, be advised that any 
> dissemination, copying, distribution or any other similar activity is 
> legally prohibited and may be punishable. If you received this e-mail by 
> mistake please advise the sender immediately by using the reply facility in 
> your e-mail software and delete permanently this e-mail including any 
> copies of it either printed or saved to hard drive. 
> 
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
> www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy 
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru 
> przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 
> 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 
> 168.955.696 złotych. 
> 
> -- 
> For IBM-MAIN subscribe / signoff / archive access instructions, 
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
> 
 
-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN