Where and how are credentials stored for mounted network drives?

General Discussion
1

I’m sure that they are securely kept. I just want to know where and how :slight_smile:

2

I found it. I answer my own questions too often :sweat_smile:.

/var/lib/dietpi/dietpi-drive_manager

Stored in plain text :confused:, but “protected” with file level permissions (chmod 0600, chown root:root).

3

For the record…I did not mark my own answer as the solution :joy:.

Thanks @Joulinar lol

I wouldn’t know the first thing about it, but how could this be made more secure, so the creds aren’t stored in plain text?

Store them in the keyring some how?

4

On a headless system keyrings are not preinstalled and it’s also not a pretty “diet” way to do so.
IMO the actual implementation is safe enough. If somebody get’s root access everything is lost anyways :slight_smile:

But to answer your question in a more technical way: Hashing is not an option, bc the drive manager needs it in plain text.
So an option would be some sort of encryption, but then you need to know a key and you need to store the key somehwere, so you got a new problem.

But it’s really quite common to store it as plain text and restrict the access to root (or some other user), for example fstab does this for smb credentials, or you store it in a file.smbcredentials also in plain text.
wpa_supplicant.conf does it too, and .netrc and many more :slight_smile:

5

I ask Gemini AI for an answer :slight_smile:

Summary: For 99% of use cases, a chmod 600 file is the industry standard for securing SMB shares on Debian.

advanced more complex alternatives

If you require hardware-level encryption or higher security:

  • LUKS: If your root partition is encrypted via LUKS, the credentials file is physically secure when the system is off.
  • Systemd-creds: Modern versions of Systemd (available in newer Debian releases) allow for encrypted credentials managed by the system manager.
  • Kernel Keyring: You can use the keyutils package to store secrets in the kernel’s RAM-based keyring, though this is significantly more complex to automate at boot.

So Gemini agrees with @Jappe on the methodology here. As mentioned earlier, in order to read the file, the attacker must gain root privileges or at least obtain root access. Hopefully, this wouldn’t happen in a home lab. However, if the system is located within the internet, the scenario would certainly be different.

BTW

It’s not our drive manager who needs this. :wink: