0

I have been using a separate credential file for Samba as it seems to be the "suggested" way to make things "more secure". However, I have also been trying to figure out how exactly this makes your system any more secure.

My thought is, regardless if you put the credentials directly in fstab or in a separate cred file, the credentials are stored as plain text either way. If someone has compromised your system to the point they can access /etc/fstab, then they now know where the cred file is, what it is named, and most likely can also gain access to it regardless of it's permissions.

I can see this maybe being useful for a multi-user computer in a work environment to keep each user from accessing each others "personal network storage" share by storing the credential file somewhere in their personal /Home folder. But for single user, home computers, does using a credential file really make anything more secure, or is it, just making you "feel" like it is?

If it does actually make things more secure, what are the best practices for storage location, and permissions to it?

To be clear, I am talking about for a home based user, accessing a share on a local server for access to media and a file backup location.

Improve this question
8
  • Forget about my comments: I misread samba for cifs. Anyway there's surely something related to multi-user or not.
    – A.B
    Commented Aug 21, 2022 at 22:03
  • In a home environment, the only other person that might access my computer would be my wife. Who already has access to the shares I am connecting to on the server anyway.
    – Maverickz
    Commented Aug 21, 2022 at 22:04
  • I think it's a matter of forming good habits, i.e. which configuration you think of as "the default" and which one a deviation from default. People suggest using a separate credential file because it's the safe choice that should generally be the default option unless you know exactly when it's safe to deviate from it (e.g. on a PC). Whereas if people said, "put password= in fstab unless you're doing this on a shared system", many wouldn't pay attention to it even in situations when they should have. (It's a bit like with the electrical installation Code over at DIY.SE, minus the fires.)
    – grawity_u1686
    Commented Aug 21, 2022 at 23:03
  • In other words, if the baseline is "unsafe but low effort" and making it safer is additional stuff to do, then nobody wants to put in the extra effort to make it safe even when it's needed, compared to "safe but more effort needed" being the baseline that you consciously skip certain parts when you know those aren't useful in your situation. (Whether it's passwords in fstab, or c not recommending chmod 0777 on any error, or not recommending yo disable the firewall instead of figuring out ports...)
    – grawity_u1686
    Commented Aug 21, 2022 at 23:22
  • @user1686 The question isn't to do it or not. The question is how much safer is it actually making things? If all it does is wrap a layer of toilet paper around an exiting safe, then is it really worth any effort? If it is putting a safe around an existing roll of toilet paper, then obviously it is worth doing. That is what I am trying to understand. How much extra safety does this actually add? Honestly, it doesn't seem like much based on my current understanding. I am trying to improve my understanding. Saying "do it, because you should" isn't helping me understand the why.
    – Maverickz
    Commented Aug 21, 2022 at 23:30

1 Answer 1

Reset to default
0

For single-user systems, it most likely makes no difference as the same password can be also found in many other places under your own account, e.g. on Linux it is likey stored within GNOME Keyring where any of your programs could read it.

Though it does increase the chance that your password might leak as part of the fstab entry being deliberately or accidentally, e.g. when copy-pasting configuration to your notes or when sending system logs to help someone investigate a problem with your system. (For example, a graphical file manager may keep fstab contents in memory, etc.)

This is similar to passwords in command line, or in system logs – in theory on a single-user system the log files wouldn't be seen by anyone else but you, until one day you post your system logs on a GitHub issue and your password is accidentally in there.

Finally, the "suggestion" you've found is not just given for single-user systems exclusively; often it is given to, or found by, admins of multi-user systems where it does make a lot of difference.

If someone has compromised your system to the point they can access /etc/fstab, then they now know where the cred file is, what it is named, and most likely can also gain access to it regardless of it's permissions.

No, because /etc/fstab is generally accessible to all processes and all users by default, so having access to it does not in any way imply that "most likely" you can read other files regardless of their permissions.

So if you get access to run code on a webserver e.g. as the "http" user (through a compromised PHP webapp, for example), that is still a long way to go from actually having root privileges.

Accessing a system as unprivileged user does not automatically imply compromise – it is still very common to have multi-user systems (both servers and workstations) where people other than the owner can legitimately log in. The common /etc/shadow file, containing user password hashes, is also protected mainly by file permissions.

If it does actually make things more secure, what are the best practices for storage location, and permissions to it?

When the share is mounted on boot, the credentials file must also be accessible at that point (keeping in mind that boot process has several stages – network filesystems may be mounted before certain other things happen). Putting it in /etc is guaranteed to work (/etc/private might be a suitable place).

Putting the file in someone's personal /home may make sense if the share is only accessible to that one user (using the file_mode mount option, for example), but this gets into opinion territory entirely.

Mounts in fstab are processed with root privileges, so the file only needs to be readable by root – and usually the whole point is that it's not readable by "world". (Although root can read files without read permissions granted it's still conventional to make such files explicitly readable and usually writable by root, i.e. 0600 or 0400 rather than 0000 permission bits.)

Improve this answer
1
  • Thank you. That answered my question. I also like the idea of /etc/private for location. I don't have the rep to upvote or I would but I did accept as the answer.
    – Maverickz
    Commented Aug 22, 2022 at 0:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .