On Tue, Apr 9, 2024 at 5:17 AM Robert Elz wrote:
> Sure, it is possible to make a useless program like this ...
> Almost all real commands use stdio to read stdin. Playing about
> any more with this absurd example isn't worth the bother. The relevant
> text should simply be deleted from POSIX
Date:Mon, 8 Apr 2024 19:35:02 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| Why not? It works fine with other shells
Sure, it is possible to make a useless program like this ...
| $ cat tst.sh
| cat
Hmm, looks like I'm partially mistaken.
Vim never does the inode pivot trick *in circumstances where I might've
noticed*, so not when the file:
- has multiple links, or
- is a symlink, or
- is in an unwritable directory, or
- otherwise appears to be something other than a plain file.
But it turns
On Tue, 9 Apr 2024 10:42:58 +1200
Martin D Kealey wrote:
> On Mon, 8 Apr 2024 at 01:49, Kerin Millar wrote:
>
> > the method by which vim amends files is similar to that of sed -i.
> >
>
> I was about to write "nonsense, vim **never** does that for me", but then I
> remembered that using ":w!"
On Mon, 8 Apr 2024 at 01:49, Kerin Millar wrote:
> the method by which vim amends files is similar to that of sed -i.
>
I was about to write "nonsense, vim **never** does that for me", but then I
remembered that using ":w!" instead of ":w" (or ":wq!" instead of ":wq")
will write the file as norm
On Mon, Apr 8, 2024 at 5:32 PM Robert Elz wrote:
> The effect is that sharing stdin between the shell script, and other
> commands (than read), is almost certainly never going to work,
Why not? It works fine with other shells
$ cat tst.sh
cat
Date:Mon, 8 Apr 2024 12:32:13 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| The only ash clone that does this is gwsh, all others print "a" and a
| command-not-found error.
I have (today, after your e-mail) changed the NetBSD shell so it works
like is (apparent
On 4/7/24 12:17 AM, ad...@osrc.rip wrote:
Hello everyone!
I've attached a minimal script which shows the issue, and my recommended
solution.
Hi. Thanks for the report. This seems more like a case of mistmatched
expectations.
Bash tries, within reason, to read its input a command at a time, a
On Apr 08 2024, Greg Wooledge wrote:
> Now imagine what happens if the shell is killed by a SIGKILL, or if
> the system simply crashes during the script's execution. The script
> is left with altered permissions.
Or the script is executed by more than one process at the same time.
--
Andreas S
On Mon, Apr 08, 2024 at 02:23:18PM +0300, ad...@osrc.rip wrote:
> Btw wouldn't it be possible (and worth) temporarily revoking write access to
> the user while it's being executed as root, and restoring original rights
> after execution?
I think that would be a huge overreach. It would also lead
On 2024-04-08 14:02, Greg Wooledge wrote:
On Mon, Apr 08, 2024 at 12:40:55PM +0700, Robert Elz wrote:
or perhaps better just:
main() { ... } ; main "$@"
You'd want to add an "exit" as well, to protect against new lines of
code being appended to the script.
Yes that is correct. it's far ea
On Mon, Apr 08, 2024 at 12:40:55PM +0700, Robert Elz wrote:
> or perhaps better just:
>
> main() { ... } ; main "$@"
You'd want to add an "exit" as well, to protect against new lines of
code being appended to the script.
On Mon, Apr 8, 2024 at 5:58 AM Robert Elz wrote:
> Shells interpret their input in much the same way, regardless of
> from where it comes. Would you really want your login shell to
> just collect commands that you type (possibly objecting to those
> with syntax errors) but executing none of them
On Mon, 8 Apr 2024, at 5:29 AM, John Passaro wrote:
> if you wanted this for your script - read all then start semantics, as
> opposed to read-as-you-execute - would it work to rewrite yourself
> inside a function?
>
> function main() { ... } ; main
Mostly, yes. My initial post in this thread sp
On 2024-04-08 05:58, Robert Elz wrote:
Date:Mon, 8 Apr 2024 02:50:29 +0100
From:Kerin Millar
Message-ID:
<20240408025029.e7585f2f52fe510d2a686...@plushkava.net>
| which is to read scripts in their entirety before trying to execute
| the resulting program. To go ab
Date:Mon, 8 Apr 2024 00:29:41 -0400
From:John Passaro
Message-ID:
| if you wanted this for your script - read all then start semantics, as
| opposed to read-as-you-execute - would it work to rewrite yourself inside a
| function?
|
| function main() { ... }
if you wanted this for your script - read all then start semantics, as
opposed to read-as-you-execute - would it work to rewrite yourself inside a
function?
function main() { ... } ; main
On Sun, Apr 7, 2024, 22:58 Robert Elz wrote:
> Date:Mon, 8 Apr 2024 02:50:29 +0100
> From:
Date:Mon, 8 Apr 2024 02:50:29 +0100
From:Kerin Millar
Message-ID: <20240408025029.e7585f2f52fe510d2a686...@plushkava.net>
| which is to read scripts in their entirety before trying to execute
| the resulting program. To go about it that way is not typical of sh
On Mon, 08 Apr 2024 00:23:38 +0300
ad...@osrc.rip wrote:
> On 2024-04-07 16:49, Kerin Millar wrote:
> > On Sun, 7 Apr 2024, at 5:17 AM, ad...@osrc.rip wrote:
> >> Hello everyone!
> >>
> >> I've attached a minimal script which shows the issue, and my
> >> recommended
> >> solution.
> >>
> >> Aff
On Mon, Apr 08, 2024 at 12:23:38AM +0300, ad...@osrc.rip wrote:
> - Looks for list of PIDs started by the user, whether it's started in
> terminal or command line, and saves them into $DotShProcessList
> - Takes $DotShProcessList and filters out those that don't have root access.
> Those that do
On 2024-04-07 16:49, Kerin Millar wrote:
On Sun, 7 Apr 2024, at 5:17 AM, ad...@osrc.rip wrote:
Hello everyone!
I've attached a minimal script which shows the issue, and my
recommended
solution.
Affected for sure:
System1: 64 bit Ubuntu 22.04.4 LTS - Bash: 5.1.16(1)-release -
Hardware:
HP P
On Sun, 7 Apr 2024, at 5:17 AM, ad...@osrc.rip wrote:
> Hello everyone!
>
> I've attached a minimal script which shows the issue, and my recommended
> solution.
>
> Affected for sure:
> System1: 64 bit Ubuntu 22.04.4 LTS - Bash: 5.1.16(1)-release - Hardware:
> HP Pavilion 14-ec0013nq (Ryzen 5 550
You do realise that if you allow an untrusted script to run at root, having
it modify itself is the least of your concerns. There are *so* many ways an
untrusted script can cause a problem that do not require your
self-modifying script and for which your proposed mitigation will do
nothing. What's
Hello everyone!
I've attached a minimal script which shows the issue, and my recommended
solution.
Affected for sure:
System1: 64 bit Ubuntu 22.04.4 LTS - Bash: 5.1.16(1)-release - Hardware:
HP Pavilion 14-ec0013nq (Ryzen 5 5500u, 32GB RAM, Radeon grapics, nvme
SSD.)
System2: 64 bit Ubuntu 2
24 matches
Mail list logo
