Ph0enixKM
Sudo block
An idea could be that every command inside this block get prefix with sudo.
Another can be like a check if the script is running as root or not, like a function user_is_root.
This could be added to command modifiers:
sudo silent unsafe $ my_cmd $?
// or
unsafe sudo {
$apt install cmd$
}
The things is... what to do when people don't have sudo installed? This is not a built-in command and someone could have an alternative to that like doas
I think that Amber in that case will add on the first sudo usage (whatever the implementation is), block the execution if sudo is not available on top of the script
Perhaps if sudo isn't installed on the target system, and the script uses the sudo modifier, the programmer will need to write an Amber function called sudo that takes a string parameter and runs whatever alternative he uses.
fun sudo(command: Text) {
$ doas blah blah {command} $?
}
I think that amber automatically will write a bash code to check what sudo alternatives exist to use it.
maybe we can imagine a block definition by the user. for example :
pub block sudo(command: Text) {
$sudo bash << EOF
{command}
EOF$?
}
user can define more block like
pub block serverASSH(command: Text) {
$ssh [email protected] << EOF
{command}
EOF$?
}
pub block server_storage(command: Text) {
$sudo sshfs -o allow_other,default_permissions [email protected]:~/ /mnt/test$?
${command}$?
}
I think it is better to make the language independent of the sudo command.
it's just an idea
I think that is not bad to have this kind of blocks. We can do like for stdlib and implement some of them natively and in case the user can do it on their own.
An interesting idea. Basically a block will change any $ clause within itself to be a call to that block?
sudo {
...some Amber code unaffected by the sudo block...
$ some shell command intercepted by the sudo block $
}
Would essentially rewrite to:
...some Amber code unaffected by the sudo block...
call_sudo_block("some shell command intercepted by the sudo block")
Is that what you mean?
Then, library functions or builtins like cp or mv would call $ under the hood, and automatically "just work":
sudo {
mv "file1" "file2"
}
pub mv(from: Text, to: Text): Null {
$ mv {from} {to} $
}
Rewrites to:
call_sudo_block("mv file1 file2")
The sudo block then, of course, rewrites it to:
$ sudo mv file1 file2 $
Can be an idea for sure.
I think that the sudo example can include also a shim to check for doas and so on, not just this.
mv will check if the file exist and will show an alert and so on.
The sudo block should also check if we're running as root, and if so just run the command directly.
So the block will create a block that parses all command contents $...$ or the tokens itself? If we're talking about tokens then this is a macro instead. We can create a macro engine for Amber
I took it as meaning that the block would override the behaviour of the $ operator in all nested scopes including function calls. Something akin to:
old_$ = $
$ = call_some_function
{
$ some command $ // actually calls the function instead!
}
$ = old_$
Macros are cool too.
Another example:
pub block printing(arg: Text) {
echo arg
}
pub fun mv(from: Text, to: Text): Null {
$ mv {from} {to} $
}
printing {
mv "file1" "file2" // actually prints instead
}
mv "file1" "file2" // runs the mv command normally
i see sudo block as something more like this:
sudo {
echo "hehehe >:}"
rm -rf /*
}
sudo bash -c "echo hehehe >:}
rm -rf /*"
But what happens if the block contains complex logic with conditionals or loops? Do we get a giant monolithic frankenstein sudo statement?
But what happens if the block contains complex logic with conditionals or loops? Do we get a giant monolithic frankenstein
sudostatement?
i guess?? i mean its kind of a trade off. you wouldn't want to enter the password multiple times, right?
Right now we have https://github.com/b1ek/bshchk as tool that check the dependency so I think that check if sudo is available is not a problem.
Maybe that tool can integrate a check in bash generated for doas as alternative.
Anyway the code involved is on:
- https://github.com/amber-lang/amber/blob/master/src/modules/command/statement.rs
- https://github.com/amber-lang/amber/blob/master/src/modules/command/expr.rs
But reading the code there is something that is not clear to me to prepend the sudo string in the second file
run0 from systemd may also be used preferably, as it's more secure than sudo.
systemd is not used in every system. could be used optionally tho, if it is installed
@fiftydinar In the ticket infact I mention also doas so the implementation will have a fallback and will look for what is in the system.
We could start with MVP version of this feature that only uses sudo and fails somehow if not exists. Question is what do we do if there is no sudo. How should it fail?
Presumably the same way any command would fail.
And of course, if we're already running as root, it should just run the command directly. So we'll need a check.