make is a utility for end users or for programmers/developers?

Anyway, in addition to docker, as an alternative, could I also use the following command?

Code:
$ sudo -u devel make ...
sudo: unknown user devel
sudo: error initializing audit plugin sudoers_audit
Obviously I have to create the user devel.

It's best to just login as your target user, a'la su -l devel. Then build. The reason is you need devel to have the correct environment. To provide devel's full environment sudo -iu devel will do. Just calling sudo -u devel runs a command as devel, but things like PATH are inherited from your current login. So it's best to fully switch to your devel user to ensure everything is correct when building in an isolated environment. You'd also need to ensure devel belongs to the right group(s), a'la usermod -aG <each,group,needed> devel. Of course this does get cumbersome, which is why I just build things as myself, lol. But I'm the only person using my machine, so my only reason for even having a user account is security.
 


It's best to just login as your target user, a'la su -l devel. Then build. The reason is you need devel to have the correct environment. To provide devel's full environment sudo -iu devel will do. Just calling sudo -u devel runs a command as devel, but things like PATH are inherited from your current login. So it's best to fully switch to your devel user to ensure everything is correct when building in an isolated environment.

Wait...
Let me understand ...

Which of the following two commands should I use?

Code:
$ su -l devel
$ sudo -iu devel

What is the difference?

You'd also need to ensure devel belongs to the right group(s), a'la usermod -aG <each,group,needed> devel.

The right group
That is?

Of course this does get cumbersome, which is why I just build things as myself, lol.

You can see that you can keep everything under control, and you don't have my problem of biting your tail.

Reread https://www.linux.org/threads/make-...for-programmers-developers.53813/#post-250499

Just here is the matter (let's keep it in mind).

But I'm the only person using my machine,

OK, I understand :)

so my only reason for even having a user account is security.

OK... I do not understand :(
Could you explain yourself better?
 
Which of the following two commands should I use?
Code:
$ su -l devel
$ sudo -iu devel
Whichever you prefer...
su -l <user> will log you in as that user with that user's environment. As in fully simulating the login. just su <user> or sudo -u <user> <command> do not do this, then environment is inherited from the user running it (that's you in this case.
sudo -iu <user> will long you in as the target user.
man sudo
man su

What is the difference?
Superficially, none. Going deeper, it depends on your system. A properly configured sudo-system limits access and allows granular controls. This would include preventing the use of su. But most sudo systems are not. And most do not need to be because they're single user desktops. So I don't even use sudo on my rig.
Sorry if I confused you, I just want to outline that you had choice because Linux is about choice.

The right group
That is?
Entirely based on what your development user needs access to. So, for one example, you may need access to removeable storage or network devices, so plugdev and netdev... This is where you need to use a websearch for your specific needs. You may have to add your own user group to be able to access your files, but then this removes the isolation part. This is very much a preference versus practice thing and it'll be a merry-go-round so I suggest

Could you explain yourself better?
Not much more than I have. The problem if we're jumping from one thing to another, and there's going to be a lot of confusion as one item bleeds into the next. So maybe let's keep it simple and avoid the elaborate. Here's a proof-of-concept (PoC) script for hacky VCS:
I'm calling it "vcs_make.sh". Copy it into the same dir as you'd run make and run it instead.
Bash:
#! /bin/bash

# !! Run this in the directory containing makefile !!

# Need this info later (you'll see)
iiAppDir=$(basename "$(pwd)")

# Create a suffix for backup directories. Change the format as you see fit
iiBackupSuffix="bkp_$(date +%Y-%m-%d__%H-%M.%S)"

# You can add sanity, I'm too lazy (run configure if it exists)
if [ -e "configure" ]; then
./configure
fi

# Okay, build!
make

# You can add sanity check code here, too, I'm too lazy.

# Goes up, copies the app to a time-stamped backup.
# Note you can use tar and xz to archive larger builds...But this is PoC code, use it as boilerplate
cd ..
cp -r "$iiAppDir" "$iiAppDir.$iiBackupSuffix"
cd "$iiAppDir"

There. You can now use this. Please note I haven't tested it so check for typos, etc. If you don't know what's going on, feel free to ask, but I suggest you just do a 30-min crash course on Bash or ask Bing/WhateverAI to help improve it and make it useable.
 
[codice]
Fare
[/codice]

Vedi sotto

[codice]
CD..
[/codice]

Perché?

[codice]
cp -r "$iiAppDir" "$iiAppDir.$iiBackupSuffix"
[/codice]

Perché dopo il comando make?

PS

Ho l'impressione che la sceneggiatura vada rivista
 
Entirely based on what your development user needs access to. So, for one example, you may need access to removeable storage or network devices, so plugdev and netdev... This is where you need to use a websearch for your specific needs. You may have to add your own user group to be able to access your files, but then this removes the isolation part. This is very much a preference versus practice thing and it'll be a merry-go-round so I suggest

What do you suggest?

Code:
make

See below

Code:
cd ..

Why?

Code:
cp -r "$iiAppDir" "$iiAppDir.$iiBackupSuffix"

Why after the make command?

PS

I have the feeling that the script needs to be revised

There. You can now use this. Please note I haven't tested it so check for typos, etc. If you don't know what's going on, feel free to ask, but I suggest you just do a 30-min crash course on Bash or ask Bing/WhateverAI to help improve it and make it useable

What needs to be improved?
What are you referring to?
 
What do you suggest?
Sorry, I must have backspaced when formatting... "...so I suggest 'you maybe keep things simple for your needs.' "

Why?
Why after the make command?
Because we go up a directory so we can create a clone of that build using cp -r (the r being for "recursive")
And we do make first because the package needs to first be built before we clone it and label that build, else you'd just be making copies of the source code.

I have the feeling that the script needs to be revised
What needs to be improved?
What are you referring to?
Yes, of course it needs to be revised. It's boilerplate for you to use to make something useful. It's also a proof of concept so you can get an idea of how to implement this in your chain. That's why I recommend you learn a little Bash, so you can make something really kickass for yourself. It's very rewarding to make your own utilities, even if it/they isn't/aren't on par with enterprise stuff. Try it, I guarantee you'll have fun. Even if it's not a crude version system. Even if you just say, "What's a simple annoyance I have daily/weekly?" and then write a script that smooths it out.
 
Bash:
#!/bin/bash

iiAppDir=../$(basename "$(pwd)")
iiBackupSuffix="bkp_$(date +%Y-%m-%d__%H-%M.%S)"

[[ -e "configure" ]] && ./configure
make

cp -r \
    "$iiAppDir" \
    "$iiAppDir.$iiBackupSuffix"

but wouldn't it be better [[ -f "configure" ]] ?
 
No, the intention should all ways be, that all following questions are answered as clear, as detailed as possible :
1. Are all dependencies documented
2. The version of used tools (also the sources of the tools) must be given
3. Refer to https://en.wikipedia.org/wiki/Reproducible_builds, all recommendations must be fulfilled, that e.g.: after 10 years someone could rebuild the sources with the same binary result.
4. ...

Therefore the question should be, what we can learn from industrial standard like ISO9001, DO178C ... !!!
Ignore the reply by this forum, professional SW development has another way.
I am sorry, but the terminus wizard in context of linux does no give no sense anymore. Linux is established. Higher SW qualification verification procedures has do be installed.
I hope Linux developers does understand my hint.
 
Whichever you prefer...
su -l <user> will log you in as that user with that user's environment. As in fully simulating the login. just su <user> or sudo -u <user> <command> do not do this, then environment is inherited from the user running it (that's you in this case.
sudo -iu <user> will long you in as the target user.
man sudo
man su
Anyway, among the differences I found (actually I found only one), there is one regarding the PATH

Code:
+ su -l OTHER_USER
$ echo $PATH && exit
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
logout

+ sudo -iu OTHER_USER
$ echo $PATH && exit
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
logout

If it may be of interest...
 
Anyway, among the differences I found (actually I found only one), there is one regarding the PATH
I'm guessing OTHER_USER is root based on sbin being in PATH... sudo -iu should load the target user's full environment. It seems your root user has extra fluff like /usr/local/games/ in PATH. Now with sudo, there's a default config in sudoers called secure_path which enforces that executables outside of secure_path cannot be called implicitly ... If you were to disable secure_path, the results should then be the same for both su -l and sudo -iu -- though I wouldn't recommend disabling secure_path more than testing once-off as my first thought is: it'd allow a user to run a user-editable script as root! TBH I'd forgotten about that little quirk.

So, in short, there's no difference in specified behaviour, but there's a difference in a real-world scenario provided secure_path's enabled -- which it is by default. Good catch.
 
I'm guessing OTHER_USER is root based on sbin being in PATH...
NO.
Sorry, maybe it's better to be specific

Code:
+ su -l devel
$ echo $PATH && exit
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
logout

+ sudo -iu devel
$ echo $PATH && exit
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
logout

sudo -iu should load the target user's full environment. It seems your root user has extra fluff like /usr/local/games/ in PATH. Now with sudo, there's a default config in sudoers called secure_path which enforces that executables outside of secure_path cannot be called implicitly ... If you were to disable secure_path, the results should then be the same for both su -l and sudo -iu -- though I wouldn't recommend disabling secure_path more than testing once-off as my first thought is: it'd allow a user to run a user-editable script as root! TBH I'd forgotten about that little quirk.

So, in short, there's no difference in specified behaviour, but there's a difference in a real-world scenario provided secure_path's enabled -- which it is by default. Good catch.
In light of my correction, I now don't know how valid your explanation is.
 
It's still valid. secure_path applies to all sudo-based logins. I assumed it was root only based on sbin (I did wonder how root ended up like that but had it down to preference or a once-off, for-this-session, thing). Anyway, as I say, the behaviour will be the same regardless of what accounts you sudo into.
 
If you were to disable secure_path, the results should then be the same for both su -l and sudo -iu
Curiosity: How to disable it secure_path?


but now I don't have time to document myself

-- though I wouldn't recommend disabling secure_path more than testing once-off as my first thought is: it'd allow a user to run a user-editable script as root!

it'd allow a user to run a user-editable script as root!

Meaning what?
 
Last edited:
Curiosity: How to disable it secure_path?
but now I don't have time to document myself
You could just comment it out, though it's better if you did do the research yourself. Memory is retained better when you do hands-on research.

it'd allow a user to run a user-editable script as root!
Meaning what?
Well, let's make an example:
/home/james/.local/bin/app is a great little CLI-based Text Adventure game in Bash. I wrote it. I love it. But only I can run it implicitly (without typing "/home/james/.local/bin/app", ie just typing "app") because "/home/james/.local/bin" is in my PATH. But now I can edit that script as a user. So if I do something dumb and malware overwrites part of it, well it'll cause some problems, but it won't kill my entire system. However, if root could run it implicity (example "sudo app") because root's PATH contained "/home/james/.local/bin/" then that's be very serious. Hypothetical: It could say, download a version of firefox from the attacker's site which had a keylogger and/or fake "DNS" (overriding resolv.conf & co. because it gets your queries first), then replace /usr/bin/firefox with the fake. Next time you browse, everything looks normal, but sites can be spoofed, keystrokes (thus sign-ins) can be logged, and so on.
 
You could just comment it out, though it's better if you did do the research yourself. Memory is retained better when you do hands-on research.
OK, but let's make it short this time?

First I would like to understand which file needs to be modified.

File time I read somewhere that you need to modify the file /etc/sudoers by giving the following command

Code:
$ sudo visual

Is that right?

Well, let's make an example:
/home/james/.local/bin/app is a great little CLI-based Text Adventure game in Bash. I wrote it. I love it. But only I can run it implicitly (without typing "/home/james/.local/bin/app", ie just typing "app") because "/home/james/.local/bin" is in my PATH. But now I can edit that script as a user. So if I do something dumb and malware overwrites part of it, well it'll cause some problems, but it won't kill my entire system.

So if I do something dumb

What do you mean.
I don't understand.
could you explain better?

and malware

What malware?
Maybe you meant "a malware"

overwrites part of it


What part?
 
OK, but let's make it short this time?
Code:
$ sudo visual
Is that right?
No.
To edit the sudoers file it's visudo, not "visual". The reason for this is it provides a safer environment than just a plaintext editor. man visudo for more.

So if I do something dumb
What do you mean.
I don't understand.
could you explain better?
So if you do something dumb: download and run a random app/script off the internet, copy&paste stuff you don't understand into the terminal, etc.

What malware?
Maybe you meant "a malware"
Malware: https://en.wikipedia.org/wiki/Malware
If you want to split hairs, "malware" is a non-countable noun, so we don't use "a", it's just "malware" or "a piece of malware".

overwrites part of it
What part?
Any part. The beginning would be good to ensure it ran...
Just for laughs let's take the "app" script hypothetical I mentioned. So say I want to put something malicious in it:
WhereToInsert="$(grep -n "#!" app | cut -c1-1)i"; sed -i "$WhereToInsert echo Pwned" app;
Explanation: Get the position of #! so we can run our malicious code first, before the app runs. Then use sed to insert a malicious command. Finally app cat be run with sudo because there's no secure_path.

A worse case: If I just echo'd a malicious script to $HOME/.local/bin/dd and chmod'd it with a+x, you'd really be in a world of hurt because without a proper root login or an enforced secure_path, sudo would inherit your user environment and $HOME/.local/bin/dd would be prioritised over /usr/bin/dd when you ran sudo dd.

I'm really not going any deeper on this topic as I feel uncomfortable posting a real exploit (or linking to one). I reiterate: if you're interested, read up on security.
 
You could just comment it out, though it's better if you did do the research yourself. Memory is retained better when you do hands-on research.
Code:
$ sudo grep secure_path /etc/sudoers
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

So I should just comment out the line

Code:
#Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

Right?
 
Code:
$ sudo grep secure_path /etc/sudoers
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

So I should just comment out the line

Code:
#Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

Right?
Yup. It's not recommended, but it'll work if that's your desired outcome.
 

Staff online

Members online


Top