Yes, an attacker who has compromised your PC has compromised your PC.
https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#Why-arent-physically_local-attacks-in-Chromes-threat-model

https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#Does-the-Password-Manager-store-my-passwords-encrypted-on-disk explains how passwords are encrypted on disk. The encryption key is stored in KWallet or GnomeKeyring.

A very general scenario would be,
I will sign out of all my accounts and let my friend watch a movie on my PC.
Here, it is my PC, so there is no malicious program running in background.
If my friend knows about this file, he can easily get to know my password for multiple accounts. 

The *only* safe way to share your PC with an untrusted person is to use a Guest (or equivalent unprivileged) operating system login account. This is a fundamental fact of computer security, not unique to web browsers. 

I would like to know why the password is encrypted and not in plain text On Windows and Mac, but it is visible and readable on Linux?

This clearly is a bug.

As per the link above, 
====================================
On Linux, credentials are stored in an encrypted database, and the password to decrypt the contents of that database are stored in KWallet or Gnome Keyring. (See  Issue 602624 .)
====================================

Without using any decryption mechanism, we are able to read the exact password from "Login Data" using vi editor on linux.

There is no advantage of using the encrypted database, if passwords are visible.

All the passwords saved by google are compromised.

While it's completely expected that a user can read their own password file (even if encrypted), it is indeed unexpected that the user can use a text editor to view the plaintext without bothering to retrieve the key from one of the keystores.

cfroussios@, can you PTAL? Is this a duplicate of Issue 619485?

> I would like to know why the password is encrypted and not in plain text
> On Windows and Mac, but it is visible and readable on Linux?

On Windows, the password is encrypted using a secret available to the current user-account. When logged in as the current user, the data is 
directly readable and the system automatically decrypts it. On Mac, it works in a similar way with the slight modification that the decryption key is stored in the user's keychain rather than being a built-in property of the user-account. On Linux, it's expected to work the same way, with the decryption key stored in either the KWallet or Gnome Keyring.

On Linux, the password is stored directly into Keyring or Kwallet. The password will be stored in the profile directory (.../Default/Login Data) only if neither Keyring nor Kwallet are available. Since our encryption key is kept in Keyring/KWallet too, if we have to store the password in the profile directory, we also have to store it without encryption.

The caveat here is that we only use Keyring/KWallet if it's a standard part of the environment, otherwise we ignore it. We don't want to save important data into any service we discover, because the user may have added it temporarily.

Can you check your Keyring/KWallet and verify that Chrome hasn't written anything into it? If so, then this works as intended.

1. Keyring is installed.
$ rpm -qa | grep gnome
libgnome-keyring-3.8.0-3.el7.x86_64

2. Can you check your Keyring/KWallet and verify that Chrome hasn't written anything into it? If so, then this works as intended.

=> I do not see a keyring folder in ~/.local/share or ~/.gnome

What I understand is, although Keyring is installed, "Login Data" is not being encrypted.

As I said, Keyring being installed is not the condition itself. To use Keyring, we have to determine that the environment is Gnome, or a similarly compatible and known environment .

Our list captures the vast majority of what people use. https://cs.chromium.org/chromium/src/components/os_crypt/key_storage_util_linux.cc?rcl=cdb2f9649d924f7cb4b0866ca6fbf7ea55c08b45&l=55

What is your environment? Can you compare that to what Chrome sees, by running
[chrome executable] --enable-logging --vmodule=*/os_crypt/*=1 
and looking into
[profile path]/../chrome_debug.log
You can find your user data directory by visiting chrome://version

Marking low severity for now.

So, I found the following log:
 [11019:11044:0123/022501.232847:VERBOSE1:key_storage_util_linux.cc(53)] Password storage detected desktop environment    : (unknown)
I understand that since, it does not have a compatible environment, passwords are not encrypted.

But, it violates the principle of "security by default"
If passwords cannot be encrypted, they should not be saved. 

That's a good point.
Vaclav, can you answer why it was decided to keep password manager enabled when encryption is unavailable?

I can't speak to the particular decision here, but will note that encrypting passwords is really only a defense-in-depth anyway. 

In general, having applications encrypt their own files doesn't make a lot of sense, because the decryption key is (necessarily) available to the application. That means that in an attacker in a position to steal the encrypted files (e.g. they're running malware in the user's account) is also usually in a position to steal the decryption key. Local data encryption is useful only in narrow threat models where the attacker is so constrained that they can steal the file but for whatever reason cannot steal its decryption key. 

In contrast, phishing (a threat which the password manager serves as a solid mitigation) is a more prevalent threat vector, so that it would be a poor security tradeoff to increase the user's vulnerability to phishing solely because they are also vulnerable to local data theft.

The general comment #15 fits very well on the specific case of passwords in Chrome.

Thank you for clarifying for me.
With all that in mind, I'm marking this as wontfix.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot