New Linux Users | pitfalls and differences | Win/Linux

I suppose there is some logic there. The workstation is the default version designed for everyone of every experience level and is possibly being made to be more difficult to break.
Other spins are for those with more in-depth knowledge and wanting to think outside the box and try something different, so more relaxed security conditions may be in effect. The other spins are not even on the default download page.

It’s not a spin but the Fedora Everything iso has the option to set a root password.

Overloading a word with multiple different meanings causes confusion. I use “GNU/Linux” for the operating system, “Linux” for the kernel. It helps introducing GNU and free software.

Regarding:
1: case sensitivity is a file system option, isn’t it?

3: lsblk does not require administrative rights

4.1.1: sudo passwd root is not necessary, i.e. use sudo su

5: for advanced users:
getfattr - get extended attributes of filesystem objects
getfacl - get file access control lists
SELinux/AppArmour

6: file extension, not file name

6.1: you can run files without x-bit with bash file

7: that depends on configuration; in addition you could specify the absolute or a relative path, f.i. “./” or “../”

8.1: the trailing % must be left out as depicted in the example

9: good place to mention software and specifications (XDG!) from https://www.freedesktop.org

note: info pages help too

Booaarrhh,
now you have opened a barrel.

Example 1: I am the father of a family and am the sole administrator of the system.
Already here I would rather deal with PolicyKit than get any members into a Sudo/Wheel group. In the very detailed ManPage over many pages there are two ways described. Edit the existing “/etc/polkit-default-privs.local” or create your own user specific units.

Example 2: I have a large corporate server with multiple admins to manage. There sudo is certainly important and correct because there is only one real admin and some who are allowed to perform these tasks in case of emergency and/or vacation etc… All other users are served with PolicyKit again, for example to log into a WLan.

What I want to say is that Sudo for a single computer with only one user is complete nonsense.

I can be corrected however gladly.

EDIT: Ohh, I just see that it’s not handled like in OpenSuse.
Now I have to check which files they are.

EDIT2: Soo, I have looked again:
The correct files are below

root@fedora:/etc/polkit-1# ls -la
insgesamt 28
drwxr-xr-x.   5 root    root     4096  4. Mai 23:30 .
drwxr-xr-x. 150 root    root    12288  6. Aug 18:26 ..
drwxr-x---.   7 root    polkitd  4096 21. Jan 2022  localauthority
drwxr-xr-x.   2 root    root     4096 21. Jan 2022  localauthority.conf.d
drwx------.   2 polkitd root     4096  4. Mai 23:30 rules.d

and are to be understood like this.

  1. global -configuration, preset
  2. actions
  3. rights

1 In linux the file system is case sensitive, no options.
In windows case is immaterial.

3 This paragraph does not reference a need for sudo or su to execute the lsblk command.

4.1.1 sudo passwd root is required to set a password for root before the su - command can be used.

No problem i integrated it anyway to get all the audience satisfied :wink: :

I was trying to check, but I could not prove it yet. @sobek also refers to sudo su and not su -

As I understood, sudo and root have per default the same rights. Exception is that root is not logged in the security log. While the user who elevates with sudo gets logged. Meaning, if you can change the root passwd you can elevate your selves to root (su) while get logged ?!

as mentioned above … i not could prove it yet.

Speaking only of defaults in this.
Any action taken using sudo will be logged.
Using su or sudo su will be logged, but actions taken after gaining the root account privileges will not.
This is why it is critical for security on a multi-user system that the usage of sudo is enforced and that only truly trusted administrators are members of the wheel group. Others with sudo privileges should have limited access to specific commands only so they can do what is needed but not able to truly gain full root privileges.

Yes, members of the wheel group have essentially the same rights as the actual root user, but their actions using sudo are logged. Once they use sudo su then further actions are not logged until they log out of that terminal session (exit from the sudo command).

If the root user has a password set (is not locked) then su or su - can be used by anyone who knows that root password. Again a security issue for keeping the password knowledge to a limited few. Use of su is logged, but nothing else once the elevation of privileges is complete.

Recent testing I have done shows that virtually all the spins available at https://spins.fedoraproject.org/ as well as the Everything ISO allow setting a root user password during install. The Workstation install (which most new users will likely use) does not allow setting a root password during install and thus requires the use of sudo for that purpose.

Just an FYI.
Use of su elevates the user to root, but retains the users original environment. Use of su - gives the root users environment and replaces that of the original user. Thus the environment is the only significant difference in the two forms of that command.

Another FYI:
I did a bit of editing on that first post to fine tune some features that were a little ambiguous and to clarify the meaning. Your efforts are highly appreciated and I thought to assist a little bit.

1 Like

1 In linux the file system is case sensitive, no options.
In windows case is immaterial.

I am referring to man 8 mkfs.xfs

The version=ci option enables ASCII only case-insen‐
sitive filename lookup and version 2 directories.
Filenames are case-preserving, that is, the names
are stored in directories using the case they were
created with.

and man mkfs.ext4

encoding=encoding-name
Enable the casefold feature in the super block and
set encoding-name as the encoding to be used. If
encoding-name is not specified, the encoding defined
in mke2fs.conf(5) is used.


3 This paragraph does not reference a need for sudo or su to execute the lsblk command.

My bad. I meant 3.1.


4.1.1 sudo passwd root is required to set a password for root before the su - command can be used.

True. But I wrote sudo su. There it is not required.

$ grep root /etc/passwd
root:x:0:0:root:/root:/bin/bash
$ sudo grep root /etc/shadow
root:!::0:99999:7:::
$ sudo su
#

As I understood, sudo and root have per default the same rights. Exception is that root is not logged in the security log. While the user who elevates with sudo gets logged.

sudo ssh ${NAME}@${HOST} will save to “/root/.ssh”, i.e. the user’s command gets executed as root.

What is meant with “is not logged in the security log”? I see actions in sudo journalctl -f.

paragraph 4.1.1 says

4.1.1 To get a Terminal like root@yourhostname you can use su - and enter the root user’s password or sudo -i and enter your personal account’s password. On Fedora Linux, the root user’s password will need to be set with sudo passwd root before su - will work.

There it says specifically that the root password must be set before you can use su -. It also says that you can use sudo -i instead with the users password. Just to clarify, there are several ways to use sudo and elevate to root. These include sudo -i, sudo su, sudo su - and probably others. Paragraph 4.1.1 does not say that the root password needs to be set to use sudo.

ahhh, yes, PolicyKit2, nice stuff!

All other users are served with PolicyKit again, for example to log into a WLan.

Please, elaborate about this use-case and details. I am intrigued.

What I want to say is that Sudo for a single computer with only one user is complete nonsense.

It saved me a few times from myself >P

@computersavvy thank you for correction. It was fused in my mind the other day. My bad.

Running su is logged. It happens in /etc/pam.d/postlogin which is called from /etc/pam.d/su. The difference is that every command isn’t logged when you run su - (well, it sorta is, but it is logged in root’s ~/.bash_history instead). Plain sudo (without the -i) will log every command in systemd’s journal. But sudo -i will not. sudo -i is really the same thing as su - with the exception that the former asks for the user’s password but the latter asks for root’s password.

ANY command executed beginning with ‘sudo’ will be logged. Executing the ‘su’ command will be logged.

Any command executed by the root user is not logged. This means that

  1. commands executed by a user logged in as root are not logged. (except in the root users ~/.bash_history)
  2. commands executed by a user who has already been elevated to root by use of ‘sudo su’ or ‘su’ will no longer be logged (except in the root users ~/.bash_history) for as long as they retain the root level permissions…

So we are talking about when /root/.bash_history and when /home/user/.bash_history gets written?
As far as I know for Bash as loginshell this is only ever updated when the terminal session ends, i.e. is true for user account too. I do not know if this behavior is different for other shells (zsh, csh, fish, …).

I cannot see the sudo su root accounts with loginctl (su not tested). I can see them with ps l | grep sudo and use the PPID to look up PID’s user.

There are lots of different places different things are logged.
last, journalctl, /var/log, .bash_history, are only a few of the locations to find specific things.

You will need to do your own research, but a quick search for 'what is logged in security log in linux` will give you a ton of links to start with.

That is the reason why I asked what is being referred to.

Not so sure your first point here is really a pitfall, instead an advantage.
Having an operating system that is case sensitive such as Linux does have an advantage.

I have my own personal web site where I display all my artwork, sort of an on-line art gallery.
I put together all the html, css, and other coding. When I first started used Windows operating system for creating html pages and checked everything through browsers off-line. Things would look okay on Windows off-line yet after uploading to my web service and having things run on the web all kinds things were quite dfferent since my service was Linux based server. I would go back and check how things looked on different browsers and would find all kinds of things that did not show up on the pages. This was due to a situation where I would carelessly type upper case letters instead of lower case or vice versa. Using the same browser off-line things looked perfect, using the same browser on-line linked to my service all kinds of problems discovered with lower and upper case situation. Now, a better system is test off-line using a Linux operating system before uploading, this would catch any type of case sensitive problems before you present your web site to the public. In my opinion this is one advantage of using Linux to catch case sensitive problems.

I do not think item 1 was intended to refer to a pitfall, so much as a cautionary note pointing out the difference in the OSes. A user has to learn and acclimate to using a case sensitive OS.

Windows is absolutely not case sensitive, but linux is and always has been. Thus a windows user who ignores case when typing commands (or even text) on linux hits a brick wall with the requirement to use everything exact in a case sensitive environment. As you describe, it is easy to see that when a windows user types (on a command line in windows) ‘cd DOWNLOADS’ or ‘cd Downloads’ or ‘CD downloads’ the effect is the same. On a linux system those are 3 different effects and the last is not even a valid command.

What you describe is a typical learning curve when confronted with the differences in the way case is handled when a windows user is confronted with a *nix operating system

File names containing spaces (whitespace) is also a significant difference that becomes an issue.

I think this is very individual, in my case it was a struggle. Beside watching the grammar I had to check also the case :wink: