@stocksami: "I am trying to use it with linux Mint.  I run mysqld as root and I see a 
process running.  Now what.  I've tried the MySQL Administrator GUI and 
I can't connect.  I tried to run mysqladmin as root to set a password 
and I get a message saying Access denied for user root using password: 
NO.  Is there a beginning password built into mysqld?  What do I have to 
run to establish a database?
I'm just learning SQL so I don't know much about this stuff.  I am 
fairly valeriesmith@example.com."
    @bsdSANSPAM: "<quote>
I think, you're not following a distro specific policies and, or have
build your own mysql binaries from sources.
It is better to use pre-packaged binary builds on decent distros like
Debian, Ubuntu and, or LinuxMint, try:
sudo aptitude update
sudo aptitude dist-upgrade
sudo aptitude install mysql-server mysql-client
and then:
sudo service mysql-server start
or
sudo invoke-rc.d mysql-server start
or even:
sudo /etc/init.d/mysql-server start
finally:
# I think, no password is required for user 'root'; 'cause on above
# said distros the mysqld by default is configured to listen only on
# localhost (83.161.120.155/32)
mysql -u root
...
Hope that helps,
Balwinder S "bdheeman" Dheeman        Registered Linux User: #229709
Anu'z Linux@HOME (Unix Shoppe)        Machines: #168573, 170593, 259192
Chandigarh, UT, 160062, India         Plan9, T2, Arch/Debian/FreeBSD/XP
Home: <url>      Visit: <url>"
    @wbogaerts: "<quote>
If I recall correctly (on Xubuntu, not Linux Mint), I had to provide a 
mysql-root password upon installation of MySQL. If Linux Mint provides 
its own mysql root password, you'd better ask in a Linux Mint forum or 
newsgroup.
If you have given one but forgot it, the documentation 
(<url> can 
tell you how to set a new one. But it may also help to just reinstall 
mysql with the help of the package manager of Linux Mint.
If you do know the root password, you will have to provide it:
"mysql -u root" will connect to the local database server with user root 
with no password. ("mysql" is the command-line client)
"mysql -u root -pYourPassword" will connect with user root and password
"YourPassword". Note that this password will also be added to your 
command-line history and this is therefore not very safe.
"mysql -u root -p" will first ask you for the root password and then 
connects to the server with the password you typed. This will not be 
added to the command history and is therefore safer.
Hope this helps,
Willem Bogaerts
Application smith
Kratz B.V.
<url>"
    @stocksami: "<quote>
I'm not sure how a password got set, but I was able to get around it 
with help from the following link.  It is disturbing that it is so easy 
to get around the password.
<url>
I was also given some instructions on the MySQL forum:
<url> "
    @tnp: "<quote>
once you have root permissions, you can compromise anything on a *nix 
box. Myqsql is not different."
    @jurgenex: "On Wed, 24 Feb 2010 10:17:20 -0800, A Watcher <email_address>
wrote in comp.databases.mysql:
<quote>
If it is so easy to get root access to your operating system then I
would worry about many, many other security breaches first.
jue"
    @stocksami: "<quote>
It's not easy to get root access to linux if you don't have the password.
MySQL is an application.  I suppose it makes sense that if you are root 
on the system that you should be able to get into an application."
    @tnp: "<quote>
hell, if you can shove a DVD in the drive, you can boot into super user 
without knowing the valeriesmith@example.com.
If you have a screwdriver, you can remove the hard disks and mount them 
on any *nix system you HAVE got root access to. and read and write 
anything you want.
without root security AND physical security, all the obscure security 
you think you have, is totally useless."
    @stocksami: "<quote>
If physical security is important then the HD can be encrypted.  My 
former employer did that on all PCs.  Obviously with enough computer 
power encryption can be broken, but most thieves aren't in that category."
    @gordonbuf7bq: "<quote>
Root has enormous power.  So does having physical access to the
machine.  You can't really protect against either - once they get
root access or physical access to the machine, it's pretty much
game over.  You need to stop them before that.  You can try to
protect against these with old-fashioned security:  locked rooms,
guards with guns, cameras everywhere, disconnecting the network
cable, etc.
If this guy is *authorized* to have root access (e.g. he's an
employee of the hosting company you use), those won't stop him.
About the only prayer you have of protecting application data from
root is encryption, and then you have to realize that root has the
power to watch anything going into or out of an application process.
Root can also booby-trap an application process that's open source
(or, harder but possible:  non-open-source) to log passwords or
encryption keys.  If the objective is to *read* sensitive stuff
(say, credit card numbers) in the database, extracting a backup
tape on another machine controlled by the admin is very hard to
detect.  Admins are expected to make backup copies.
Admins are expected to be able to restart the system in case of
power failure (one long enough to drain a UPS) or system crash, so
passwords entered on bootup (e.g. for encrypted filesystems) aren't
really a solution.  That's problematic for protecting your SSL-based
web server from the admin, who can get to the private key of your
certificate.
Root can copy or move databases, hard disks, or other stuff over
to another system to look at or modify.  Root can take a copy of a
fresh-installed 'mysql' database (which contains all the permissions)
with a known new password, and copy it over the existing 'mysql'
database, giving full access to everything else.  Root doesn't get
the original password, but still gets all access.  Hard disks can
be moved to a system with special boot roms, or you could just boot
from CD-ROM.
Tamper-proof smart cards are an attempt to deal with this.  As seen
by failed attempts to use this to copy-protect cable TV, satellite
TV, and DVDs, this gets cracked.
I once constructed a version of cron that took an encrypted crontab
file.  I challenged another sysadmin to figure out what it was
doing.  6 days later (I hadn't accessed the file then, and the
encrypted version of cron was still running) he told me "Go see
what I did to your file".  I looked, then told him "You did nothing
to the file.".  In 15 minutes, he gave me a copy of the file.  How?
He modified the crypt(1) command to log passwords.  When I didn't
*use* the crypt(1) command for a while, he tricked me into using it."
    @gordonbca4gj: "<quote>
So how does the hard disk get decrypted?  Who enters a password on
boot?  If the password is stored somewhere on hard disk, then it's
easy to get to that area if you know where it is (and the boot code
*must* know this), possibly by temporarily transplanting the hard
disk to another machine."
    @tnp: "<quote>
Up to a point, yes, but for routine use the decryption algorithm must 
also be on the machine, and in some way, the key as well."
    @tnp: "<quote>
Yup.
Its amazing how often registering with a given site, results in an 
increase in spam on matters loosely concerned with the nature of the 
site you register with.
My hypothesis is more than one sysadmin routinely is selling contact 
info to marketing organisations.
Smartass....
The point being with all of this that with intelligence and ingenuity, 
nothing is safe from root. And physical access to a typical machines is 
de factor root access.
Which is why many organisations prefer not to use hosting companies, but 
pay for their own high speed links and host their servers in their own 
secure locations.
People worry about using ssh, to access remote machines. Ha! I am far 
more worried about what is happening where that remote machine is. I've 
set up machines in colocation places. Security is OK, but I remember 
looking at a competitors machines on the same rack I was working on, and 
thinking..'now if I were an immoral person, a little ethernet card in my 
machine, and a little repeater under the floor..would never be 
noticed..' the work of a second to install.
I regard all information on shared and coloc hosting as essentially 
public domain, if not de jure, certainly de facto. If its valuable 
information, sooner or later someone will offer someone else enough 
money to get to it."
    @tnp: "<quote>
There are ways round this. I wrote a system that used a flash drive on a 
portable. The flash held the mysql and the sensitive stuff is encrypted. 
The portable held the obfuscated, but not uncrackable, key.
its used to do remote point of sales stuff away from any connectivity 
options.
The theory being that the laptop and the stick are never connected 
together except when  a valid operator is present. Either one or the 
other may get stolen, but only the two together contain the full secret 
of the encryption.
One could use such a system to boot-with-key and then remove the key, 
and hope the key was always RAM resident.
Not total proof against root on a running system, but proof against 
booting from cold without the key."
    @stocksami: "<quote>
I suspect the key was generated from your login id and password.  You 
would have to know the login and the decryption logic in order to read 
the HD."
    @stocksami: "<quote>
My employer went to great lengths to keep employees and contractors in 
separate sand boxes.    I retired and then returned as a contractor 
doing the exact same job.   When I came back I had a lot of trouble just 
doing my usual work because of these precautions.
But then they hired contractors to do all of the computer installation 
and maintenance work.  That made no sense whatsoever."
{'source': 'USENET', 'other_information': '{"reply_count": 15, "forum_name": "comp.databases.mysql.20141228.mbox"}', 'file': 'data/output/usenet-comp.databases.parquet'}