How evil is this: echo bash >> .bashrc
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
I was thinking of playing a prank on someone by running one of the following commands:
echo bash >> .bashrc
or
echo source .bashrc >> .bashrc
If someone did this to you, what could you do to fix it (assuming you only have command line access)? Is there anything you could do, short of asking another user to edit it with sudo?
bash bashrc
asked Jun 7 at 15:12
vikarjramun
1336
 |Â
show 2 more comments
up vote
2
down vote
favorite
I was thinking of playing a prank on someone by running one of the following commands:
echo bash >> .bashrc
or
echo source .bashrc >> .bashrc
If someone did this to you, what could you do to fix it (assuming you only have command line access)? Is there anything you could do, short of asking another user to edit it with sudo?
bash bashrc
asked Jun 7 at 15:12
vikarjramun
1336
1
The second will just appear to hang that bash process, so another user can repair it. I think the first one will eventually bring the whole system down due to the increasing number of processes spawned (think "fork bomb"). So, yeah, evil. Less evil, but as annoying would beecho exec bash >> .bashrc
– glenn jackman
Jun 7 at 15:27
3
Also less evil and more prankish would beecho exec csh >> ~/.bashrc.
– DopeGhoti
Jun 7 at 15:36
On my machines where my login shell is the Z shell, the Korn shell, and even sometimes the TENEX C shell, it would not do anything to me at all, which indicates that you haven't defined the terms of the question properly. Define "command-line access". Does it include SSH? Is the user logged in at the time? Is the Bourne Again shell even the user's login shell in the first place?
– JdeBP
Jun 7 at 15:51
Do you have ssh access?
– ctrl-alt-delor
Jun 7 at 15:53
1
Not evil at all, but frightening if you don't expect it: Install hollywood und put it in .bashrc
– mviereck
Jun 7 at 19:46
 |Â
show 2 more comments
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I was thinking of playing a prank on someone by running one of the following commands:
echo bash >> .bashrc
or
echo source .bashrc >> .bashrc
If someone did this to you, what could you do to fix it (assuming you only have command line access)? Is there anything you could do, short of asking another user to edit it with sudo?
bash bashrc
asked Jun 7 at 15:12
vikarjramun
1336
I was thinking of playing a prank on someone by running one of the following commands:
echo bash >> .bashrc
or
echo source .bashrc >> .bashrc
If someone did this to you, what could you do to fix it (assuming you only have command line access)? Is there anything you could do, short of asking another user to edit it with sudo?
bash bashrc
asked Jun 7 at 15:12
vikarjramun
1336
asked Jun 7 at 15:12
vikarjramun
1336
asked Jun 7 at 15:12
vikarjramun
1336
asked Jun 7 at 15:12
vikarjramun
1336
1336
1
The second will just appear to hang that bash process, so another user can repair it. I think the first one will eventually bring the whole system down due to the increasing number of processes spawned (think "fork bomb"). So, yeah, evil. Less evil, but as annoying would beecho exec bash >> .bashrc
– glenn jackman
Jun 7 at 15:27
3
Also less evil and more prankish would beecho exec csh >> ~/.bashrc.
– DopeGhoti
Jun 7 at 15:36
On my machines where my login shell is the Z shell, the Korn shell, and even sometimes the TENEX C shell, it would not do anything to me at all, which indicates that you haven't defined the terms of the question properly. Define "command-line access". Does it include SSH? Is the user logged in at the time? Is the Bourne Again shell even the user's login shell in the first place?
– JdeBP
Jun 7 at 15:51
Do you have ssh access?
– ctrl-alt-delor
Jun 7 at 15:53
1
Not evil at all, but frightening if you don't expect it: Install hollywood und put it in .bashrc
– mviereck
Jun 7 at 19:46
 |Â
show 2 more comments
1
The second will just appear to hang that bash process, so another user can repair it. I think the first one will eventually bring the whole system down due to the increasing number of processes spawned (think "fork bomb"). So, yeah, evil. Less evil, but as annoying would beecho exec bash >> .bashrc
– glenn jackman
Jun 7 at 15:27
3
Also less evil and more prankish would beecho exec csh >> ~/.bashrc.
– DopeGhoti
Jun 7 at 15:36
On my machines where my login shell is the Z shell, the Korn shell, and even sometimes the TENEX C shell, it would not do anything to me at all, which indicates that you haven't defined the terms of the question properly. Define "command-line access". Does it include SSH? Is the user logged in at the time? Is the Bourne Again shell even the user's login shell in the first place?
– JdeBP
Jun 7 at 15:51
Do you have ssh access?
– ctrl-alt-delor
Jun 7 at 15:53
1
Not evil at all, but frightening if you don't expect it: Install hollywood und put it in .bashrc
– mviereck
Jun 7 at 19:46
1
1
The second will just appear to hang that bash process, so another user can repair it. I think the first one will eventually bring the whole system down due to the increasing number of processes spawned (think "fork bomb"). So, yeah, evil. Less evil, but as annoying would be
echo exec bash >> .bashrc– glenn jackman
Jun 7 at 15:27
The second will just appear to hang that bash process, so another user can repair it. I think the first one will eventually bring the whole system down due to the increasing number of processes spawned (think "fork bomb"). So, yeah, evil. Less evil, but as annoying would be
echo exec bash >> .bashrc– glenn jackman
Jun 7 at 15:27
3
3
Also less evil and more prankish would be
echo exec csh >> ~/.bashrc.– DopeGhoti
Jun 7 at 15:36
Also less evil and more prankish would be
echo exec csh >> ~/.bashrc.– DopeGhoti
Jun 7 at 15:36
On my machines where my login shell is the Z shell, the Korn shell, and even sometimes the TENEX C shell, it would not do anything to me at all, which indicates that you haven't defined the terms of the question properly. Define "command-line access". Does it include SSH? Is the user logged in at the time? Is the Bourne Again shell even the user's login shell in the first place?
– JdeBP
Jun 7 at 15:51
On my machines where my login shell is the Z shell, the Korn shell, and even sometimes the TENEX C shell, it would not do anything to me at all, which indicates that you haven't defined the terms of the question properly. Define "command-line access". Does it include SSH? Is the user logged in at the time? Is the Bourne Again shell even the user's login shell in the first place?
– JdeBP
Jun 7 at 15:51
Do you have ssh access?
– ctrl-alt-delor
Jun 7 at 15:53
Do you have ssh access?
– ctrl-alt-delor
Jun 7 at 15:53
1
1
Not evil at all, but frightening if you don't expect it: Install hollywood und put it in .bashrc
– mviereck
Jun 7 at 19:46
Not evil at all, but frightening if you don't expect it: Install hollywood und put it in .bashrc
– mviereck
Jun 7 at 19:46
 |Â
show 2 more comments
1 Answer
1
active
oldest
votes
up vote
4
down vote
accepted
You can not edit the other user's shell startup files unless the permissions are set insecurely. Doing it without their knowledge or consent (which goes for any file in their home directory) would be considered unethical and may also be considered a breach of conduct, depending on what rules of conduct are in effect on the system.
If you have sudo rights on the system, and consider playing this "prank", then you should not have sudo rights on that system.
The first command would add bash as a command at the end of .bashrc. If this was .bashrc in the user's home directory, and if the user was a bash user, then this would cause an infinite recursive loop of interactive shells to be started (as soon as one such shell session was initiated), until terminated or running into resource restrictions.
The second command would cause a similar loop, but the code would only run in a single bash process environment. This would continue until terminated, or until some environment variable (like PATH, if the script added to it in each iteration) got too big at which point a resource limit would be reached.
On a multi-user system, both of these "pranks" may affect other users as shared resources (CPU and memory mostly) are consumed.
Editing, correcting and then saving the .bashrc file while the above scenarios are ongoing would halt the loop, but would not release resources until the bash process(es) of the affected user were terminated.
As a panic fix, one would be able to halt it using pkill -U username bash as root, or with pkill bash as the affected user. This would terminate all bash processes of the affected user.
answered Jun 7 at 15:47
Kusalananda
101k13199312
1
These sort of pranks are normally done when someone forgets to lock their session and walks away, otherwise I'd call it "cheating". They can actually be useful to encourage following security measures (locking the screen when walking away) so long as they're harmless. Commonly though it's just echo some funny message in the bashrc. In that instance, the prank doesn't stop someone from using the machine, and is easy to fix, which is generally how I'd recommend doing these pranks.
– Centimane
Jun 7 at 15:56
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
accepted
You can not edit the other user's shell startup files unless the permissions are set insecurely. Doing it without their knowledge or consent (which goes for any file in their home directory) would be considered unethical and may also be considered a breach of conduct, depending on what rules of conduct are in effect on the system.
If you have sudo rights on the system, and consider playing this "prank", then you should not have sudo rights on that system.
The first command would add bash as a command at the end of .bashrc. If this was .bashrc in the user's home directory, and if the user was a bash user, then this would cause an infinite recursive loop of interactive shells to be started (as soon as one such shell session was initiated), until terminated or running into resource restrictions.
The second command would cause a similar loop, but the code would only run in a single bash process environment. This would continue until terminated, or until some environment variable (like PATH, if the script added to it in each iteration) got too big at which point a resource limit would be reached.
On a multi-user system, both of these "pranks" may affect other users as shared resources (CPU and memory mostly) are consumed.
Editing, correcting and then saving the .bashrc file while the above scenarios are ongoing would halt the loop, but would not release resources until the bash process(es) of the affected user were terminated.
As a panic fix, one would be able to halt it using pkill -U username bash as root, or with pkill bash as the affected user. This would terminate all bash processes of the affected user.
answered Jun 7 at 15:47
Kusalananda
101k13199312
1
These sort of pranks are normally done when someone forgets to lock their session and walks away, otherwise I'd call it "cheating". They can actually be useful to encourage following security measures (locking the screen when walking away) so long as they're harmless. Commonly though it's just echo some funny message in the bashrc. In that instance, the prank doesn't stop someone from using the machine, and is easy to fix, which is generally how I'd recommend doing these pranks.
– Centimane
Jun 7 at 15:56
add a comment |Â
up vote
4
down vote
accepted
You can not edit the other user's shell startup files unless the permissions are set insecurely. Doing it without their knowledge or consent (which goes for any file in their home directory) would be considered unethical and may also be considered a breach of conduct, depending on what rules of conduct are in effect on the system.
If you have sudo rights on the system, and consider playing this "prank", then you should not have sudo rights on that system.
The first command would add bash as a command at the end of .bashrc. If this was .bashrc in the user's home directory, and if the user was a bash user, then this would cause an infinite recursive loop of interactive shells to be started (as soon as one such shell session was initiated), until terminated or running into resource restrictions.
The second command would cause a similar loop, but the code would only run in a single bash process environment. This would continue until terminated, or until some environment variable (like PATH, if the script added to it in each iteration) got too big at which point a resource limit would be reached.
On a multi-user system, both of these "pranks" may affect other users as shared resources (CPU and memory mostly) are consumed.
Editing, correcting and then saving the .bashrc file while the above scenarios are ongoing would halt the loop, but would not release resources until the bash process(es) of the affected user were terminated.
As a panic fix, one would be able to halt it using pkill -U username bash as root, or with pkill bash as the affected user. This would terminate all bash processes of the affected user.
answered Jun 7 at 15:47
Kusalananda
101k13199312
1
These sort of pranks are normally done when someone forgets to lock their session and walks away, otherwise I'd call it "cheating". They can actually be useful to encourage following security measures (locking the screen when walking away) so long as they're harmless. Commonly though it's just echo some funny message in the bashrc. In that instance, the prank doesn't stop someone from using the machine, and is easy to fix, which is generally how I'd recommend doing these pranks.
– Centimane
Jun 7 at 15:56
add a comment |Â
up vote
4
down vote
accepted
up vote
4
down vote
accepted
You can not edit the other user's shell startup files unless the permissions are set insecurely. Doing it without their knowledge or consent (which goes for any file in their home directory) would be considered unethical and may also be considered a breach of conduct, depending on what rules of conduct are in effect on the system.
If you have sudo rights on the system, and consider playing this "prank", then you should not have sudo rights on that system.
The first command would add bash as a command at the end of .bashrc. If this was .bashrc in the user's home directory, and if the user was a bash user, then this would cause an infinite recursive loop of interactive shells to be started (as soon as one such shell session was initiated), until terminated or running into resource restrictions.
The second command would cause a similar loop, but the code would only run in a single bash process environment. This would continue until terminated, or until some environment variable (like PATH, if the script added to it in each iteration) got too big at which point a resource limit would be reached.
On a multi-user system, both of these "pranks" may affect other users as shared resources (CPU and memory mostly) are consumed.
Editing, correcting and then saving the .bashrc file while the above scenarios are ongoing would halt the loop, but would not release resources until the bash process(es) of the affected user were terminated.
As a panic fix, one would be able to halt it using pkill -U username bash as root, or with pkill bash as the affected user. This would terminate all bash processes of the affected user.
answered Jun 7 at 15:47
Kusalananda
101k13199312
You can not edit the other user's shell startup files unless the permissions are set insecurely. Doing it without their knowledge or consent (which goes for any file in their home directory) would be considered unethical and may also be considered a breach of conduct, depending on what rules of conduct are in effect on the system.
If you have sudo rights on the system, and consider playing this "prank", then you should not have sudo rights on that system.
The first command would add bash as a command at the end of .bashrc. If this was .bashrc in the user's home directory, and if the user was a bash user, then this would cause an infinite recursive loop of interactive shells to be started (as soon as one such shell session was initiated), until terminated or running into resource restrictions.
The second command would cause a similar loop, but the code would only run in a single bash process environment. This would continue until terminated, or until some environment variable (like PATH, if the script added to it in each iteration) got too big at which point a resource limit would be reached.
On a multi-user system, both of these "pranks" may affect other users as shared resources (CPU and memory mostly) are consumed.
Editing, correcting and then saving the .bashrc file while the above scenarios are ongoing would halt the loop, but would not release resources until the bash process(es) of the affected user were terminated.
As a panic fix, one would be able to halt it using pkill -U username bash as root, or with pkill bash as the affected user. This would terminate all bash processes of the affected user.
answered Jun 7 at 15:47
Kusalananda
101k13199312
edited Jun 9 at 20:31
answered Jun 7 at 15:47
Kusalananda
101k13199312
answered Jun 7 at 15:47
Kusalananda
101k13199312
answered Jun 7 at 15:47
Kusalananda
101k13199312
101k13199312
1
These sort of pranks are normally done when someone forgets to lock their session and walks away, otherwise I'd call it "cheating". They can actually be useful to encourage following security measures (locking the screen when walking away) so long as they're harmless. Commonly though it's just echo some funny message in the bashrc. In that instance, the prank doesn't stop someone from using the machine, and is easy to fix, which is generally how I'd recommend doing these pranks.
– Centimane
Jun 7 at 15:56
add a comment |Â
1
These sort of pranks are normally done when someone forgets to lock their session and walks away, otherwise I'd call it "cheating". They can actually be useful to encourage following security measures (locking the screen when walking away) so long as they're harmless. Commonly though it's just echo some funny message in the bashrc. In that instance, the prank doesn't stop someone from using the machine, and is easy to fix, which is generally how I'd recommend doing these pranks.
– Centimane
Jun 7 at 15:56
1
1
These sort of pranks are normally done when someone forgets to lock their session and walks away, otherwise I'd call it "cheating". They can actually be useful to encourage following security measures (locking the screen when walking away) so long as they're harmless. Commonly though it's just echo some funny message in the bashrc. In that instance, the prank doesn't stop someone from using the machine, and is easy to fix, which is generally how I'd recommend doing these pranks.
– Centimane
Jun 7 at 15:56
These sort of pranks are normally done when someone forgets to lock their session and walks away, otherwise I'd call it "cheating". They can actually be useful to encourage following security measures (locking the screen when walking away) so long as they're harmless. Commonly though it's just echo some funny message in the bashrc. In that instance, the prank doesn't stop someone from using the machine, and is easy to fix, which is generally how I'd recommend doing these pranks.
– Centimane
Jun 7 at 15:56
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f448451%2fhow-evil-is-this-echo-bash-bashrc%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
The second will just appear to hang that bash process, so another user can repair it. I think the first one will eventually bring the whole system down due to the increasing number of processes spawned (think "fork bomb"). So, yeah, evil. Less evil, but as annoying would be
echo exec bash >> .bashrc– glenn jackman
Jun 7 at 15:27
3
Also less evil and more prankish would be
echo exec csh >> ~/.bashrc.– DopeGhoti
Jun 7 at 15:36
On my machines where my login shell is the Z shell, the Korn shell, and even sometimes the TENEX C shell, it would not do anything to me at all, which indicates that you haven't defined the terms of the question properly. Define "command-line access". Does it include SSH? Is the user logged in at the time? Is the Bourne Again shell even the user's login shell in the first place?
– JdeBP
Jun 7 at 15:51
Do you have ssh access?
– ctrl-alt-delor
Jun 7 at 15:53
1
Not evil at all, but frightening if you don't expect it: Install hollywood und put it in .bashrc
– mviereck
Jun 7 at 19:46