Creating a Simple GTK Application with C Integration
Let’s create a simple GTK application that uses a C library. We will create a C library that provides a function to add two numbers and then call this function from our Vala application.
Step 1: Create the C Library
First, create a C file named mathlib.c:
// mathlib.c
#include <stdio.h>
int add(int a, int b) {
return a + b;
}
Next, create a header file named mathlib.h:
// mathlib.h
#ifndef MATHLIB_H
#define MATHLIB_H
int add(int a, int b);
#endif
Compile the C library into a shared object:
gcc -shared -o libmathlib.so -fPIC mathlib.c
Step 2: Create the Vala Application
Now, create a Vala file named main.vala:
// main.vala
[CCode (cname = "add")]
extern int add(int a, int b);
void main() {
int result = add(5, 3);
print("The result of adding 5 and 3 is: %d\n", result);
}
so I created this…
using GLib;
[CCode (cname = "getuid")]
extern uid_t getuid ();
namespace Pamac {
class Cli: Object {
public int exit_status;
public Cli () {
exit_status = 0;
}
public static int main (string[] args) {
if (getuid () == 0) {
stderr.printf ("Error: pamac should not run as root\n");
return 1;
}
stdout.printf ("Nice One: pamac should run as expected\n");
return 0;
}
}
}
it compiles and tests like this.
[tracy@daphne builddir]$ ./pamac
Nice One: pamac should run as expected
[tracy@daphne builddir]$ sudo ./pamac
[sudo] password for tracy:
Error: pamac should not run as root
For sure - I think one argument is that it’s only a problem for AUR, and the default is for AUR to be disabled.
I don’t know, I can’t think of a legitimate case. My personal habit now is to not use sudo unless I am sure that I must, it’s trivial to prepend it and issue the command again - unlike issuing it and then trying to take it back later.
At the time, there was no issue using sudo with (*only **) the Manjaro repositories (it was even sometimes a good thing, since it bypassed the polkit layer — if it was updated in this update).
pamac -> polkit -> libpamac ... update all
sudo -> pamac -> libpamac ... update only repo
Since then, this has become a problem because the database files have been moved and must be owned by the user rather than root (if we use sudo or run0 or …).
only*: but will a user know whether they have an AUR update or not?
Pamac has a double role. If it would only act as pacman wrapper or gui it would be fine to run it via sudo. In the end it needs root rights to install packages into the system. But Pamac can act also as AUR helper and then one doesn’t want to build applications as root user. Perhaps part of the confusion of why one shouldn’t run sudo pamac but has to run sudo pacman comes from the similar name. At least i didn’t see someone complaining about sudo yay being just the same mistake as sudo pamac. So the check might not be complete - could be one needs to include whether or not the AUR is enabled. Or merely output a warning message intead of exiting.
An alternative is to add this executable script named pamac to /usr/local/bin/:
#!/usr/bin/env bash
# Save this script as /usr/local/bin/pamac and make it executable
if [[ $EUID -eq 0 ]]; then
echo "Warning: Do not use 'pamac' with 'root' privileges. It can cause permission issues."
exit 1
fi
/usr/bin/pamac "$@"
Output when pamac is used with sudo, run0, su & as a normal user::
sudo pamac update
[sudo] password for scotty:
Warning: Do not use 'pamac' with 'root' privileges. It can cause permission issues.
run0 pamac update
Warning: Do not use 'pamac' with 'root' privileges. It can cause permission issues.
su
Password:
[scott-ser scotty]# pamac update
Warning: Do not use 'pamac' with 'root' privileges. It can cause permission issues.
When run as a normal user, it will pass the pamac command arguments across to the actual pamac executable at /usr/bin/pamac:
pamac update
Preparing...
==== AUTHENTICATING FOR org.manjaro.pamac.commit ====
Authentication is required to install, update, or remove packages
Authenticating as: Scott (scotty)
Password:
==== AUTHENTICATION COMPLETE ====
Synchronizing package databases...
Refreshing extra.db...
Refreshing AUR...
Nothing to do.
Transaction successfully finished.
if [[ $(ps -o comm= $PPID) == "sudo" ]]; then
echo "Warning: Do not use 'pamac' with 'root' privileges. It can cause permission issues."
read -p "Are you sure you want to continue? (y/n): " choice
if [[ $choice != "y" ]]; then
echo "Exiting..."
exit 1
else
echo "Continuing..."
fi
fi
/usr/bin/pamac "$@"
Just make sure you have Any on your keyboard to exit the script
Small point of criticism: don’t use su without the space and the dash. Always use “su -” unless you have a very good reason not to.
Using su without the space and the dash gives you root privileges while still operating within your own environment and home directory. It’s a recipe for ending up with some of your own account’s (configuration) files becoming root-owned.
Or — if fish supports this, because I don’t know — just type a backslash before the command. This will make the shell interpret the command literally as-is, instead of looking through its hash table to see whether it’s an alias or a shell function.
Thanks for that advice. Many years have passed since I last actually used su (probably when I was on Mandrake, possibly PCLinuxOS). I’m sure that one of those distros didn’t provide sudo, so su was recommended at the time.
I don’t recall ever being instructed to run su as su - back then. Maybe running su is what eventually caused something to break, with the result being that I switched to Manjaro
One good thing about having previously used a distro without sudo is that I never developed the bad habit of adding sudo to the start of every command. I prefer to run commands as a normal user - they will let me know if elevated privileges are required (and, thanks to polkit, usually prompt me for the password without the requirement to re-enter the command).
PCLinuxOS does indeed not inlude sudo by default, although it’s available from their repositories. And Mandrake didn’t have sudo because sudo didn’t even exist yet at the time.
I rarely ever use sudo, and when I do, then it’s usually with the -i switch.
I also have sudo set up to require the password of the target account, rather than one’s own password. It is the fact that sudo by default only requires one’s own password while then allowing one full root access, which is the reason why PCLinuxOS considers it enough of a security hazard to not want to include it out-of-the-box, and they have a point with that.
This implementation is just a dirty local fix - the way I did it for myself, but it’s not a solution to a package shipped and useable across distributions.
Purely as a protection against a bad habit, by the time you implemented it yourself, you’re only ever likely to activate the warning for the purpose of showing off you’re skills in the forum
