using RM

[Diputs]

It's nearly on daily basis I get annoyed about bad and weird Bash and command line usage, often dealing with commands such as RM.

On Linux, there's no Recycle Bin ... so, instead of taking risks ... well, why not take any risks ?

How ? Well, TRY to do this (and I don't manage but I work on it), never never never never run:

rm *

or

rm -f *

or certainly not

rm -rf *

Not in command line, and CERTAINLY never in a script (or document).
Always use a path, a part of a path, or just something extra.
There is so much less damage you can do with :

rm a*

Certainly if you behold the fact that on Linux a and A is different.
For the love of whatever, don't use the CD command and then run RM with only a star.
Like this:

cd /what/could/go/wrong
rm *

Warning: DO NOT RUN THESE COMMANDS.

However, they say the best way to learn is to make mistakes.
I also did, well, 23 years ago, but I just bother about other people looking for problems.
The problem is: they force me to use scripts with these things, or documentation with the same.
Don't be that guy.
Or girl.

 

[MikeRocor]

In a script, I use something like

#!/bin/sh
sudo rm -rf "${1}"

The script is named "wck" (whack) and its purpose is to avoid any questions about

• file type (regular or directory)
• file ownership
• file permissions
• whether or not I'm "sure"

Whacked items are not recoverable (at least not easily) and are not copied to a recycle bin/trash can - they're just gone, as intended.

Making mistakes may not be the -best- way to learn, but it's probably the most effective. I made (most of) those mistakes back in the MS DOS 3.3 days and nowadays I (usually) don't issue commands to delete things that I don't intend delete - and if I do, well, that's on me.

 

[Diputs]

See if I get this right:
Via Sudo you get Root rights to remove any file or directory from the entire system ?

 

[truckerDave]

I'm still new to Linux. And shortly after my journey began, I created a directory called "trash". Rather than deleting a questionable (to me) file, I move it to that directory. This has saved my keester on at least one occasion that I can think of.

 

[osprey]

See if I get this right:
Via Sudo you get Root rights to remove any file or directory from the entire system ?

The answer to this query is that it depends on the security policy of the system.
Here's some relevant text from the man page:

sudo allows a permitted user to execute a command as the superuser or another user, as specified by the security policy. The invoking user's real (not effective) user-ID is used to determine the user name with which to query the security policy.

sudo supports a plugin architecture for security policies, auditing, and input/output logging. Third parties can develop and distribute their own plugins to work seamlessly with the sudo front-end. The default security policy is sudoers, which is configured via the file /etc/sudoers, or via LDAP. See the “Plugins” section for more information.

The security policy determines what privileges, if any, a user has to run sudo. The policy may require that users authenticate themselves with a password or another authentication mechanism. If authentication is required, sudo will exit if the user's password is not entered within a configurable time limit. This limit is policy-specific; the default password prompt timeout for the sudoers security policy is 0 minutes.

The upshot is that sudo can be restricted by the security policy in the sudoers file or a plugin. The default situation can vary in different systems, however, often I've found in various distros that it is, indeed, as you have suggested and sudo can assume the full rights of root and "remove any file or directory from the entire system" one way or another.

 

[MikeRocor]

See if I get this right:
Via Sudo you get Root rights to remove any file or directory from the entire system ?

Yes, basically what you said, exceptions being immutable files (I had to do that to a config file for my fm because the program insisted on pissing me off every time I closed and re-opened it) and those on read-only media.

 

[Diputs]

The answer to this query is that it depends on the security policy of the system.
Here's some relevant text from the man page:


The upshot is that sudo can be restricted by the security policy in the sudoers file or a plugin. The default situation can vary in different systems, however, often I've found in various distros that it is, indeed, as you have suggested and sudo can assume the full rights of root and "remove any file or directory from the entire system" one way or another.

But if SUDO allows you to run "as root", but then the command itself (here RM) actually doesn't read the root but the user's right ... what's the purpose of running it throught SUDO in the first place ? The goal for your example obviously is to run RM as if you are root, meaning you can remove just about anything. Which I think is a very bad idea as well because if you are not ROOT yourself, you should learn how permissions work. And if you are ROOT (real ROOT not SUDO) you know how permissons work and then it doesn't matter anymore.

 

[Diputs]

Yes, basically what you said, exceptions being immutable files (I had to do that to a config file for my fm because the program insisted on pissing me off every time I closed and re-opened it) and those on read-only media.

Yeah, it would be nice if you could remove files from DVD.
Read-only DVD that is

 

[osprey]

But if SUDO allows you to run "as root", but then the command itself (here RM) actually doesn't read the root but the user's right ... what's the purpose of running it throught SUDO in the first place ? The goal for your example obviously is to run RM as if you are root, meaning you can remove just about anything. Which I think is a very bad idea as well because if you are not ROOT yourself, you should learn how permissions work. And if you are ROOT (real ROOT not SUDO) you know how permissons work and then it doesn't matter anymore.

There are a few nuances with sudo which can differentiate it from root in some respects. When a user uses sudo to become root, the default behavior is to preserve the user's environment variables. That can be easily checked by looking, for example, at the PATH variable.

However, there are options to change this behaviour. By default, the environment has to be a mix of both user's and root's because sudo needs to have access to what root can access, so some of root's environment variables must be available to sudo. I'm thinking here of the access to /sbin which users may normally not have.

It's possible to use the -E option with sudo to preserve the user's environment, or use sudo -i to start a login shell as root, which gives you root's full environment. The configuration in /etc/sudoers may also have a bearing on which environment variables to keep or discard.

On the matter of what is a "good" or "bad" idea, it's often a matter of opinion. The basic position in linux, is a bit like it is in the C programming language it's based on. User's are provided with means and methods of great power to achieve an endless number of things, but with great power comes great responsibility because the power to create equally carries the power to destroy.

Over time, since inception, guard rails have been set in linux in various ways to forestall the messing up of systems. There are numerous such "helps" like mandatory access control systems, e.g. apparmor, authentication frameworks like polkit, and various restrictions built into applications. The freedom however, to use or discard, to configure or arrange, any or all of these systems is still available for users in linux so they are free to decide on their own levels of risk and responsibility, and so have choice, which is something that is greatly cherished in the linux community

 

[f33dm3bits]

There are a few nuances with sudo which can differentiate it from root in some respects. When a user uses sudo to become root, the default behavior is to preserve the user's environment variables. That can be easily checked by looking, for example, at the PATH variable.

There's also the option now days to use run0.

systemd Rolling Out "run0" As sudo Alternative - Phoronix

www.phoronix.com

 

[MikeRocor]

Yeah, it would be nice if you could remove files from DVD.
Read-only DVD that is

Oh, I can do that without even using sudo. Just look at the thing funny and all of sudden there's a microscopic scratch on it and -all- the files are removed.

 

[Diputs]

There are a few nuances with sudo which can differentiate it from root in some respects. When a user uses sudo to become root, the default behavior is to preserve the user's environment variables. That can be easily checked by looking, for example, at the PATH variable.

However, there are options to change this behaviour. By default, the environment has to be a mix of both user's and root's because sudo needs to have access to what root can access, so some of root's environment variables must be available to sudo. I'm thinking here of the access to /sbin which users may normally not have.

It's possible to use the -E option with sudo to preserve the user's environment, or use sudo -i to start a login shell as root, which gives you root's full environment. The configuration in /etc/sudoers may also have a bearing on which environment variables to keep or discard.

On the matter of what is a "good" or "bad" idea, it's often a matter of opinion. The basic position in linux, is a bit like it is in the C programming language it's based on. User's are provided with means and methods of great power to achieve an endless number of things, but with great power comes great responsibility because the power to create equally carries the power to destroy.

Over time, since inception, guard rails have been set in linux in various ways to forestall the messing up of systems. There are numerous such "helps" like mandatory access control systems, e.g. apparmor, authentication frameworks like polkit, and various restrictions built into applications. The freedom however, to use or discard, to configure or arrange, any or all of these systems is still available for users in linux so they are free to decide on their own levels of risk and responsibility, and so have choice, which is something that is greatly cherished in the linux community

Well, yes but my question why would you give a user ROOT like rights to remove files ..

... but NOT being root itself.

If you trust the user to be allowed to remove anything, you obviously trust the user. No ?

I think some admins use SUDO so then it's easier - but not impossible - to differentiate logins or actions between themselves (logged in as root) and via SUDO. So, it's not about SUDO really, the problem is something else.

 

[osprey]

Well, yes but my question why would you give a user ROOT like rights to remove files ..

... but NOT being root itself.

If you trust the user to be allowed to remove anything, you obviously trust the user. No ?

I think some admins use SUDO so then it's easier - but not impossible - to differentiate logins or actions between themselves (logged in as root) and via SUDO. So, it's not about SUDO really, the problem is something else.

Certainly admins can use the allocation of sudo privileges to others on a system in order to monitor them. The journal carries most, if not all of the relevant information of the operation of a sudo request and so it's available for scrutiny. For example:

$ journalctl -b | grep -i sudo
Nov 07 08:45:03 min sudo[29892]:      tom : TTY=pts/2 ; PWD=/home/tom ; USER=root ; COMMAND=/usr/sbin/parted -l
Nov 07 08:45:03 min sudo[29892]: pam_unix(sudo:session): session opened for user root(uid=0) by tom(uid=1000)
Nov 07 08:45:03 min sudo[29892]: pam_unix(sudo:session): session closed for user root

Here it's clear user tom invoked sudo on /dev/pts/2 from his home directory running the parted command at 8:45:03 on November the 7th. One can understand that in the case of system problems, the sys admin in charge would be interested in the totality of operations on the machine. As for spying, I guess that's the result of mistrust.

 

[Diputs]

Certainly admins can use the allocation of sudo privileges to others on a system in order to monitor them. The journal carries most, if not all of the relevant information of the operation of a sudo request and so it's available for scrutiny. For example:

$ journalctl -b | grep -i sudo
Nov 07 08:45:03 min sudo[29892]:      tom : TTY=pts/2 ; PWD=/home/tom ; USER=root ; COMMAND=/usr/sbin/parted -l
Nov 07 08:45:03 min sudo[29892]: pam_unix(sudo:session): session opened for user root(uid=0) by tom(uid=1000)
Nov 07 08:45:03 min sudo[29892]: pam_unix(sudo:session): session closed for user root

Here it's clear user tom invoked sudo on /dev/pts/2 from his home directory running the parted command at 8:45:03 on November the 7th. One can understand that in the case of system problems, the sys admin in charge would be interested in the totality of operations on the machine. As for spying, I guess that's the result of mistrust.

OK, so you don't trust the person which you give SUDO rights. Got it.