Yes. The root user has access to all personal data, including your home folder.
If someone gets physical access to the PC, he can log in as root easily and mess with your data. If he just plugs in your hard drive, he can’t see anything relevant.
I wonder if the question is in reference to unlocking the root account and setting a password for it. I don’t know of any distros that actually have an unlocked root account and leave its password as empty, but I suppose its not completely impossible.
That being said, if an attacker gets physical access to your PC, its game over anyways. If your drive isn’t encrypted with something like LUKS, then they can just boot up a live USB of whatever distro they want, mount the drive, and have easy access to its contents.
Ideally if you want to protect your PC against physical attacks, you’ll at the minimum want some sort of drive encryption enabled, and preferably with Secure Boot enabled with your own keys enrolled if your machine supports it.
A lot of distros “lock” the root account, a locked account cannot be logged into. You can generally do this way say, usermod -L account_name to lock an account, or usermod -U account_name to unlock one (there are numerous ways to do).
I couldn’t remember if setting a password for an account auto-unlocked it, I believe at one point this was the case but wasn’t 100% sure.
While ssd’s were still expensive, I used symlinks alot to solve problems for friends where games and launchers would only put stuff on their main drive. I had a friend using a 64 gig ssd for windows 10, he had so many symlinks I ended up drawing a chart for myself so I could more easily visualize them in case anything needed to be modified or repaired later.
Most of the time they were set and forget. But every now and then they did need to be repaired, usually from user error. I do recommend keeping a hand written reminder if you plan on doing a bunch of them. Just so much nicer to have a less-fallible record of them when you do need to work on them.
There could be a problem, if the game runs in some sort of sandbox, VM or emulator. For example, if the target of the link is outside of the environment the game can see, the link will look broken for it.
The only reason the answer wouldn’t be “yes” is if for some reason the developers of that software or game specifically wrote in a check for whether or not a certain file is a symlink and coded the software to behave differently under those circumstances. There are almost no good reasons to do that.
Linux kernel is mainly C, but it does use some of the GNU extensions, and the most support is available to compile it with GCC. The kernel can be compiled with clang, but I think it’s extra work. So step 0: Get a working GCC build system.
Obtain Linux kernel source tarball and extract to a working directory. The official Linux source releases are available at kernel.org. If you are already using a Linux distribution, your distribution has some kind of way to easily get the kernel sources they use, usually through a package management tool (e.g. apt for Debian and Debian derivatives). Note that very few distributions actually distribute real “Linux” as delivered from the authoritative kernel.org source…they all maintain patchsets on top of official Linux that can be very extensive.
1a. A traditional location for source directory is /usr/src/linux-[version]. And /usr/src/linux is traditionally a symlink that points to the “currently active” kernel source.
Configure the kernel. In the kernel tree run one of the following (The actual configuration is stored in [source_path]/.config. You can copy that file from a previous kernel version to the next revision, and it will mostly work):
2a. make config. This is the original configuration script. It asks you about a 1000 yes / no / module questions one at a time. Not recommended.
2b. make menuconfig. This is the same options as make config, but in a text-based menu format, where you can use arrow keys to go back and revisit previous options. Much better.
2c. make xconfig or make gconfig or make qconfig. Same idea as menuconfig but using X Windows, GTK, or Qt, respectively, with actual windows and dialog boxes.
make clean. This deletes stale object files. This is unnecessary if you just extracted the tarball and haven’t built anything yet. There’s also make mrproper which is deeper than clean.
make.
make modules_install. This copies loadable kernel modules (in *.ko files) that were compiled during make into /lib/modules.
Optional: make install. At least this is available on my distributions sources. If you don’t do this, you just need to pull the kernel image out of [source_path]/arch/[your_arch]/boot. The filename depends on which compression was selected in configuration. For me its “bzImage”. Take this file and copy it to a location where your bootloader can get to it. Traditionally it also gets renamed to vmlinuz-[version].
Update bootloader menu entries.
Note that most distributions will also do an initramfs, which isn’t covered here. Most people don’t actually need initramfs, particularly if they compile the key early drivers into the kernel (select “yes” rather than “module”). You may need an initramfs if your root partition is encrypted and you need an early system capable of decrypting it.
Edit: Lemmy ate all my angle bracket paths, and monospace formatting.
if you still didn’t discover it, try to take a bigger picture, i don’t use mint so i don’t remeber exactly where it was, but i csn remember with the bigger picture
linux4noobs
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.