On Thu, 2002-02-28 at 08:35, Nick Wilson wrote: > Hi all, > someone told me it was a *very* bad idea to have passwords sitting in > text files on my machine.
It can be, but it's usually better than having the resource which would otherwise require a password left unprotected. For example, I use PostgreSQL, and I have a cron job that VACUUMs the database every night. Because this system is multi-user, I do not leave the database's authentication method as "trust" for the local machine. That would allow any user to connect to the db with any privileges. Instead, the cron job has the password for the SQL admin account. To make this somewhat secure, the file is owned by root.root, and is mode 0600. The password is not given to the vacuum process as an argument, it's set in the environment so it never shows in 'ps'. The admin password for the SQL server is not used for any other services. Therefore, if someone got the password, it wouldn't give them any access to any service other than the SQL server. Because of the file's permissions, the contents are only vulnerable against broken SUID applications (like the glibc HOSTALIASES bug a while back) or someone getting root access on the machine. If the latter happens, I've got bigger problems. > Okay, I can see that, I'm the root user though and I'd like to have a > little script to connect via ncftp to my remote server. (complete with > password) > > If I gave the file 600 perms would that be a risk? Another aspect of security you might want to consider is the principle of least privilege. If the file you're fetching doesn't need to be stored by the root user, then schedule it under another user's privileges. If the file is world readable, for instance, you can even change the ownership of the destination to allow an otherwise non-privileged user to fetch the file. As others have suggested, ftp probably isn't the best transfer method in terms of security... or anything else for that matter. Think of "root" as "the big hammer". Its use should be reserved for situations where no other solution is feasible.
signature.asc
Description: This is a digitally signed message part
