If no Runas_Spec is specified the command may be run as root and no group may be specified.
Incorrect. In my testing, if no Runas_Spec is specified the command may be run as any user and the -g option may be specified to select any of the target user's groups.
If no Runas_Spec is specified it is the same as (ALL). https://unix.stackexchange.com/a/13053
But if your intent is "execute as root", put (root).
The second defines a list of groups that can be specified via the -g option in addition to any of the target user's groups.
Note that is says in addition. This implies that, without specifying the second Runas_list, the target user's groups (the user's primary group and any supplementary groups to which the user belongs) can still be specified via the -g option. I confirm this on my Fedora 34 system.
If only the first is specified, the command may be run as any user in the list but no -g option may be specified.
This part:
but no
-goption may be specified
is incorrect. The -g option may still be specified to select any of the target user's groups (the user's primary group and any supplementary groups to which the user belongs).
All API requests support performing an API call as if you were another user, provided you are authenticated as an administrator with an OAuth or Personal Access Token that has the sudo scope.
do not run the installer directly as/from the 'root' account! Always use the sudo command from a non-privileged user account. This is due to variables that are different between root's environment and a user's that aren't affected by an EUID change, as well as code checks in the install itself.
When you do sudo you are running commands as root, another user in another shell and hence all of the setup that RVM has done for you is ignored while the command runs under sudo (such things as GEM_HOME, etc...). So to reiterate, as soon as you 'sudo' you are running as the root system user which will clear out your environment as well as any files it creates are not able to be modified by your user and will result in strange things happening
NOPASSWD doesn't have a major impact on security. Its most obvious effect is to provide protection when the user left his workstation unattended
rsync -chavzP --rsync-path="sudo rsync"
Make sure that the option tty_tickets is disabled for the user you are using
what does this option do?
sudo, especially combined with NOPASSWD as recommended in the comments, has no security benefits over just using the root account.
Well, there is at least one security benefit: security through obscurity. Every hacker will try to ssh root@host. But they may not think to attempt rsyncuser@host.
(Same argument used for using non-standard port instead port 22)
Now using sudo to work around the root account is not only pointless, it's also dangerous: at first glance rsyncuser looks like an ordinary unprivileged account. But as I've already explained, it would be very easy for an attacker to gain full root access if he had already gained rsyncuser access. So essentially, you now have an additional root account that doesn't look like a root account at all, which is not a good thing.
No, clumsily working around the root account in situations where it is absolutely appropriate to use it is not for good reasons. This is just another form of cargo cult programming - you don't really understand the concept behind sudo vs root, you just blindly apply the belief "root is bad, sudo is good" because you've read that somewhere.
Run commands as another user