The Linux Questions Thread: a bunch of pitfalls, but technically it's possible

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Linux Questions Thread: a bunch of pitfalls, but technically it's possible

«‹›1033 »

Tesseraction: Apr 5, 2009

Sadly no, this was in a recovery shell so ctrl+c does nothing. It's fine as said controller meant I could walk away and do other things.

# ? Jul 5, 2023 14:12

Adbot: ADBOT LOVES YOU

# ? May 23, 2024 21:28

xzzy: Mar 5, 2009

I've never ended up with a usable file system once fsck gets into the -y/hold the key down territory. The entire disk ends up in lost+found.

# ? Jul 5, 2023 14:23

Tesseraction: Apr 5, 2009

Yep! What was interesting was it was a virtual disk and despite the drive it was hosted on being fine, after the fsck didn't fix it I tried just reinstalling the OS but that failed too because the virtual disk was still erroring out.

# ? Jul 5, 2023 14:25

F_Shit_Fitzgerald: Feb 2, 2017

hazzlebarth posted:

That is the command that caused the sudo prompt. Can you check with "grep -r chown ~FSF/.*" to search for chown in your dot-files?

I think I figured it out, and I'm almost embarrassed to reveal it because I feel stupid as gently caress.

A few days ago, I was moving a bunch of files from a USB stick to my system, and I noticed that everything I was moving ended up belonging to root and being executable (even mp3 files). I wrote a simple script that takes a file name as its input and does chown [FSF] and chmod u-x on that one file to eliminate that nonsense.

Making that script non-executable and then doing source .bashrc eliminates the problem of having to type in my sudo password when my terminal opens.

I know what you all are probably going to say: "never put scripts that use poo poo like chown in your ~/bin directory" and "why the gently caress were you doing that via a script?" It's a bit funny because I was telling a friend recently: Linux has the ability to make you feel like the king of the world one moment and like the biggest loving idiot who ever lived the next.

F_Shit_Fitzgerald fucked around with this message at 14:46 on Jul 5, 2023

# ? Jul 5, 2023 14:41

Tesseraction: Apr 5, 2009

What did you name the script? .bashrc shouldn't be calling anything like that?

# ? Jul 5, 2023 14:50

F_Shit_Fitzgerald: Feb 2, 2017

Tesseraction posted:

What did you name the script? .bashrc shouldn't be calling anything like that?

I just named it "mine". bashrc doesn't call it at all but the system doesn't like for it to be sitting in my bin directory, I guess.

# ? Jul 5, 2023 14:52

xzzy: Mar 5, 2009

Something else is going on but it may not be worth digging into, no login process or system service is going to be executing scripts in ~/bin unless it's explicitly told to.

Best I got is something is sourcing everything in ~/bin, but again, it would have to be told to do that. That's not default config for anything.

Maybe you could make a new script and have it grep $PPID out of a ps command and find out what's calling it.

# ? Jul 5, 2023 14:57

ExcessBLarg!: Sep 1, 2001

F_Shit_Fitzgerald posted:

I just named it "mine". bashrc doesn't call it at all but the system doesn't like for it to be sitting in my bin directory, I guess.

You might need to dig a bit deeper on this one.

# ? Jul 5, 2023 15:10

Tesseraction: Apr 5, 2009

Yeah, it's not *massively* important but I'm really curious how your bin directory is running automatically.

Can you show us any custom lines you've added to your bash (anonymised as needed) or at least every

code:

source

call in it?

# ? Jul 5, 2023 15:10

F_Shit_Fitzgerald: Feb 2, 2017

Sure. My .bashrc file is completely normal aside from the last couple of lines:

code:

neofetch

cal
dayOfYear
fortune | cowsay -f tux  | lolcat

eval "$(starship init bash)"

cal is just the calendar command (I like to see what day it is when I start up my terminal).
dayOfYear is the "count what day of the year it is and how far into the summer we are" script I wrote. It's simply a calculation.
fortune is the little quote displayer thing that Distrotube has talked about before.

...and of course starship is my terminal line customization.

I don't know if it makes a difference but dayOfYear is set up to run without ./

# ? Jul 5, 2023 15:18

Tesseraction: Apr 5, 2009

Is dayOfYear in ~/ or ~/bin/ ?

# ? Jul 5, 2023 15:28

F_Shit_Fitzgerald: Feb 2, 2017

Tesseraction posted:

Is dayOfYear in ~/ or ~/bin/ ?

~/bin

Maybe I should have done ~/bin/dayOfYear instead..

# ? Jul 5, 2023 15:29

Tesseraction: Apr 5, 2009

Why is ~/bin in your $PATH? Have you modified it in .bashrc?

# ? Jul 5, 2023 15:34

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

~/bin is a righteous place to keep your little scripts, and has been for 40+ years. :colbert:

# ? Jul 5, 2023 15:37

xzzy: Mar 5, 2009

Contents of $PATH aren't really relevant here. Sure it's a questionable practice (even though everyone does it) but entries in there aren't going to cause scripts to run on login.

# ? Jul 5, 2023 15:37

F_Shit_Fitzgerald: Feb 2, 2017

Tesseraction posted:

Why is ~/bin in your $PATH? Have you modified it in .bashrc?

No, I haven't messed with anything about the lines I added at the bottom of .bashrc.

e: My path is
/home/FSF/.cargo/bin:/home/FSF/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

F_Shit_Fitzgerald fucked around with this message at 15:55 on Jul 5, 2023

# ? Jul 5, 2023 15:41

Tesseraction: Apr 5, 2009

Subjunctive posted:

~/bin is a righteous place to keep your little scripts, and has been for 40+ years.

xzzy posted:

Contents of $PATH aren't really relevant here. Sure it's a questionable practice (even though everyone does it) but entries in there aren't going to cause scripts to run on login.

Sure, but I'm curious how it got onto path - to my knowledge that is not there by default so I was wondering if whatever's adding it is also accidentally running everything in there once.

# ? Jul 5, 2023 15:53

ExcessBLarg!: Sep 1, 2001

Tesseraction posted:

Sure, but I'm curious how it got onto path - to my knowledge that is not there by default so I was wondering if whatever's adding it is also accidentally running everything in there once.

code:

$ tail -9 /etc/skel/.profile
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

That would be my guess. Would apply to Debian/Ubuntu. I didn't realize about ~/.local/bin though.

# ? Jul 5, 2023 16:49

Vavrek: Mar 2, 2013; I like your style hombre, but this is no laughing matter. Assault on a police officer. Theft of police property. Illegal possession of a firearm. FIVE counts of attempted murder. That comes to... 29 dollars and 40 cents. Cash, cheque, or credit card?

F_Shit_Fitzgerald posted:

Linux has the ability to make you feel like the king of the world one moment and like the biggest loving idiot who ever lived the next.

Much too long for a thread title, sadly.

F_Shit_Fitzgerald posted:

I think I figured it out, and I'm almost embarrassed to reveal it because I feel stupid as gently caress.

Also too long for a thread title ...

# ? Jul 5, 2023 17:15

Tesseraction: Apr 5, 2009

ExcessBLarg! posted:

code:

$ tail -9 /etc/skel/.profile
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

That would be my guess. Would apply to Debian/Ubuntu. I didn't realize about ~/.local/bin though.

Huh, interesting. Something new to think about with Debian-based.

F_Shit_Fitzgerald posted:

No, I haven't messed with anything about the lines I added at the bottom of .bashrc.

e: My path is
/home/FSF/.cargo/bin:/home/FSF/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

Just to sate my curiousity could try grepping for the word "mine" in your auto-run commands like dayOfYear. I'm just academically curious at this point though.

# ? Jul 5, 2023 17:21

Klyith: Aug 3, 2007; GBS Pledge Week

Tesseraction posted:

Huh, interesting. Something new to think about with Debian-based.

~/.local/bin seems to be the new standard for systemd distros, not just debian

# ? Jul 5, 2023 17:25

BlankSystemDaemon: Mar 13, 2009

~/.local/bin isn't part of the XDG Base Directory standard, but it's a recommendation made by it in some places, I think.

# ? Jul 5, 2023 17:35

Yaoi Gagarin: Feb 20, 2014

What's wrong with ~/bin

# ? Jul 5, 2023 17:39

Satire Forum Mom: Oct 4, 2003; MY CUNT DRIPS BROWN REFUSE LIKE A DIRTY HOOKAH. PS. THE BACK OF MY THIGHS ARE RIDICULOUS - COTTAGE CHEESE ANYONE?

F_Shit_Fitzgerald posted:

I think I figured it out, and I'm almost embarrassed to reveal it because I feel stupid as gently caress.

A few days ago, I was moving a bunch of files from a USB stick to my system, and I noticed that everything I was moving ended up belonging to root and being executable (even mp3 files). I wrote a simple script that takes a file name as its input and does chown [FSF] and chmod u-x on that one file to eliminate that nonsense.

Making that script non-executable and then doing source .bashrc eliminates the problem of having to type in my sudo password when my terminal opens.

I know what you all are probably going to say: "never put scripts that use poo poo like chown in your ~/bin directory" and "why the gently caress were you doing that via a script?" It's a bit funny because I was telling a friend recently: Linux has the ability to make you feel like the king of the world one moment and like the biggest loving idiot who ever lived the next.

Just a heads up - chown has a "-R" flag that allows you to change ownership of a directory and all its contents, so you don't have to write a script that does it one by one.

And when you do write scripts, you should probably name them with the ".sh" extension - it really helps to be able to quickly tell what's a script and what's not.

Also, I'm guessing the reason all the files on your USB stick were owned by root was because it was a NTFS-formatted drive and you mounted the drive as root.

I'm still not sure why scripts in your ~/bin directory are being run - I suggest writing a script like a previous poster suggested that echos out the PPID, maybe something like:

code:

#!/usr/bin/bash
date >> ~/ppid.txt
echo "Parent process ID for this script is $PPID" >> ~/ppid.txt

make it executable, place it in your ~/bin, and then run "ps aux | grep WHATEVER_THE_PPID_WAS" to find out what was running the script.

# ? Jul 5, 2023 17:44

F_Shit_Fitzgerald: Feb 2, 2017

Satire Forum Mom posted:

Just a heads up - chown has a "-R" flag that allows you to change ownership of a directory and all its contents, so you don't have to write a script that does it one by one.

And when you do write scripts, you should probably name them with the ".sh" extension - it really helps to be able to quickly tell what's a script and what's not.

Also, I'm guessing the reason all the files on your USB stick were owned by root was because it was a NTFS-formatted drive and you mounted the drive as root.

Yep, probably. I mostly use the USB stick to move stuff from my old Windows laptop to Linux - mostly music and picture files. Every time I connect the stick to Windows it always pops up an annoying "This drive needs to be repaired" message.

Will do on the .sh extension. I try to come up with creative names for my scripts but it's good "opsec".

quote:

make it executable, place it in your ~/bin, and then run "ps aux | grep WHATEVER_THE_PPID_WAS" to find out what was running the script.

OK, easily done. Here's what the result was:

code:

FSF      17517  0.0  0.0  11408  5716 pts/0    Ss   10:21   0:00 bash
FSF      35820  0.0  0.0   9040   716 pts/0    S+     12:47   0:00 grep --color=auto 17517

F_Shit_Fitzgerald fucked around with this message at 17:55 on Jul 5, 2023

# ? Jul 5, 2023 17:53

BlankSystemDaemon: Mar 13, 2009

VostokProgram posted:

What's wrong with ~/bin

Absolutely nothing.

If anything, ~/.local/bin/ is less sensible, since by definition, the user's home directory is always part of the local installation - even if you use a combination of sysutils/pam_xdg and sysutils/pam_mkhomedir on a thin client.

# ? Jul 5, 2023 17:54

ExcessBLarg!: Sep 1, 2001

VostokProgram posted:

What's wrong with ~/bin

My guess is that ~/.local/bin exists so that user-installed (not system-wide) packages can insert themselves into PATH without having a user-visible ~/bin directory.

Like if you want a ~/bin that's fine. Preferable, even, if you write a lot of scripts that you want to be able to call by name. But if you're just doing a user-installation of an updated version of Python or something, you might not want a ~/bin, ~/lib, etc., to suddenly appear among your well-organized ~/Downloads, ~/Pictures, ~/Videos, etc.

ExcessBLarg! fucked around with this message at 18:53 on Jul 5, 2023

# ? Jul 5, 2023 17:55

xzzy: Mar 5, 2009

The concern with a ~/bin is any process you run can drop a script in there and wait for you to run it and "do bad stuff." Like say it put a script named 'ls' in there and had it send your ssh private keys to a remote server. Or whatever scenario you can come up with, it's a "security risk." One that requires you to execute sketchy programs off the internet but still a risk.

As a normal user can't write to /usr/bin the same concern doesn't exist there.

# ? Jul 5, 2023 18:01

Satire Forum Mom: Oct 4, 2003; MY CUNT DRIPS BROWN REFUSE LIKE A DIRTY HOOKAH. PS. THE BACK OF MY THIGHS ARE RIDICULOUS - COTTAGE CHEESE ANYONE?

F_Shit_Fitzgerald posted:

Yep, probably. I mostly use the USB stick to move stuff from my old Windows laptop to Linux - mostly music and picture files. Every time I connect the stick to Windows it always pops up an annoying "This drive needs to be repaired" message.

Will do on the .sh extension. I try to come up with creative names for my scripts but it's good "opsec".

OK, easily done. Here's what the result was:
code:
FSF      17517  0.0  0.0  11408  5716 pts/0    Ss   10:21   0:00 bash
FSF      35820  0.0  0.0   9040   716 pts/0    S+     12:47   0:00 grep --color=auto 17517

Oh, I should have specified you're going to have to open up a new terminal window and then check the text file for the PPID and run ps aux | grep.

# ? Jul 5, 2023 18:08

ExcessBLarg!: Sep 1, 2001

xzzy posted:

The concern with a ~/bin is any process you run can drop a script in there and wait for you to run it and "do bad stuff."

There's innumerable ways that non-sandboxed user-level processes can persist themselves even without ~/bin, which is why there's been so much focus on sandboxing over the past decade.

# ? Jul 5, 2023 18:20

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

xzzy posted:

The concern with a ~/bin is any process you run can drop a script in there and wait for you to run it and "do bad stuff." Like say it put a script named 'ls' in there and had it send your ssh private keys to a remote server. Or whatever scenario you can come up with, it's a "security risk." One that requires you to execute sketchy programs off the internet but still a risk.

As a normal user can't write to /usr/bin the same concern doesn't exist there.

seems like a lot of work versus just sending the keys to the server when the original process is running, but they can also just write to .profile or something similar if they want to interpose something. $PATH is not a line of defense against malware, other than maybe making sure that you don�t have world-writable entries in it on multi-user machines.

# ? Jul 5, 2023 18:26

BattleMaster: Aug 14, 2000

ExcessBLarg! posted:

There's innumerable ways that non-sandboxed user-level processes can persist themselves even without ~/bin, which is why there's been so much focus on sandboxing over the past decade.

wouldn't ~/.local/bin also have owner write privileges so the same thing can be done?

# ? Jul 5, 2023 18:28

xzzy: Mar 5, 2009

Subjunctive posted:

seems like a lot of work versus just sending the keys to the server when the original process is running, but they can also just write to .profile or something similar if they want to interpose something. $PATH is not a line of defense against malware, other than maybe making sure that you don�t have world-writable entries in it on multi-user machines.

Yeah it's always felt like a specious concern to me, but that's what people have said about it for like 30 years.

# ? Jul 5, 2023 18:31

Yaoi Gagarin: Feb 20, 2014

IT departments jumping at shadows is how you get poo poo like the antivirus using 25% of my CPU while linking our own software

# ? Jul 5, 2023 18:32

Klyith: Aug 3, 2007; GBS Pledge Week

I think the only reason for ~/.local/bin instead of ~/bin is that they were adding lib and share and so on to ~/.local in mirror of the traditional hierarchy under /usr. So as long as you're doing that re-org you might as well move bin in there too.

Nothing to do with security or sandboxing.

# ? Jul 5, 2023 18:45

ExcessBLarg!: Sep 1, 2001

BattleMaster posted:

wouldn't ~/.local/bin also have owner write privileges so the same thing can be done?

Yes, also ~/.config/autostart, systemd user units, etc.

xzzy posted:

Yeah it's always felt like a specious concern to me, but that's what people have said about it for like 30 years.

Putting ~/bin before system paths is problematic because you could have an executable masquerade as "sudo" and steal your credentials so that it can elevate its own privileges in ways that LD_PRELOAD or ptrace(2) are prohibited from doing. But excluding ~/bin from PATH isn't a solution because any program that inserts itself as ~/bin/sudo can also modify ~/.profile. Sure you could "chown root: ~/.profile" or whatever, but you're playing whack-a-mole at this point and the actual, defensible, solution is to sandbox untrusted executables.

Edit: To be clear, I'm not saying ~/.local/bin is any more/less problematic than ~/bin or that ~/bin is problematic in the first place. I'm saying ~/.local/bin exists, in part, because users-of-today might want to have user-installed packages without cluttering their visible home directory.

ExcessBLarg! fucked around with this message at 18:54 on Jul 5, 2023

# ? Jul 5, 2023 18:50

Truga: May 4, 2014; Lipstick Apathy

yeah i use ~/.local/* over ~/* just to keep the homedir tidy

# ? Jul 5, 2023 18:53

BlankSystemDaemon: Mar 13, 2009

Truga posted:

yeah i use ~/.local/* over ~/* just to keep the homedir tidy

If that's the goal, just call it ~/.bin.

I've been doing that for going on 20 years for my scripts, and it's worked fine.

# ? Jul 5, 2023 19:06

Kibner: Oct 21, 2008; Acguy Supremacy

Klyith posted:

I think the only reason for ~/.local/bin instead of ~/bin is that they were adding lib and share and so on to ~/.local in mirror of the traditional hierarchy under /usr. So as long as you're doing that re-org you might as well move bin in there too.

Nothing to do with security or sandboxing.

Yeah, I agree with that change both aesthetically and also making it even more obvious what is user-specific and what is system-wide.

# ? Jul 5, 2023 19:08

Adbot: ADBOT LOVES YOU

# ? May 23, 2024 21:28

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

BlankSystemDaemon posted:

If that's the goal, just call it ~/.bin.

I've been doing that for going on 20 years for my scripts, and it's worked fine.

I think the idea is that .local/ is the equivalent of /usr/local but just for that user, so it will have a hierarchy within it. I think.

# ? Jul 5, 2023 19:10

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Linux Questions Thread: a bunch of pitfalls, but technically it's possible

«‹›1033 »