From Bugzilla Helper:
User-Agent: Mozilla/4.79 [en] (Win98; U)
Description of problem:
The "password='mypass'" linein script.cfg is not encrypted nor encoded. This causes smbprint to fail if the password contains any
shel metacharacters (as a good password should). The single quotes generated around the password don't help since the password may
contain single quotes, and in any case is "eval"ed later which cancels the effects of the quotes. Additionally, there is a security
hole whenn storing plain text versions of passwords: if the script.cfg file is compomised a username and password can be obtained.
Additionally the "share='\\server\printer'" entry must encode the backslashes as forward slashes in the UNC share name. The
eval of the result cancels the effect of the single quotes. (the back-slashes could alternatively be escaped with additional
backslashes, as in "share='\\\\server\\printer'".
Version-Release number of selected component (if applicable):
Current versions as of 6/4/02 (ran up2date this morning and verified bug still present and not previously listed in Bugzilla)
Steps to Reproduce:
1.Use either printconf-gui or printconf-tui
2.Select an SMB queue
3.Use a password containing a single quote or other shell metacharacters
Actual Results: No output is produced
Expected Results: Output should have been printed
The password could be encrypted with MD5 and a randomly generated (at RH install time) password stored in a file not world-readable.
Then your tools could store the encrypted password in script.cfg, and decrypt in RAM when invoking smbprint. This solution doesn't require
using SMB encrypted passwords. As for the share name, some simple Python (or a pass using tr) will easily solve the issue. (Additional
details of this soluiton such as updating existingscript.cfg entries are left as an exersize for the reader.)
An interim solution would include adding a string to the printconf dialogs warning users to use forwad slashes in UNC names, and to use
passwordfs without any shell metacharacters for SMB passwords. But this wouldn't address the security aspect of storing plaintext passwords on the disk.
When I tried this on Red Hat Linux 7.3 a short while ago I thought this had
been fixed. I'll re-check.
Regarding the permissions on the file: it resides in a directory that only the
'lp' user may access.
If this is fixed in 7.3, could the 7.3 package be added to an otherwise 7.2 system?
I realize the directory is protected, but it seems to me still a security hole to store plaintext passwords, especially when
it would be so ease to encrypt them first.
In theory, yes, the package could just be upgraded. In practice, printing has
lots of dependencies, so you might end up pulling in more than you want. Let
me check if it really is fixed, and I'll update this bug entry appropriately.
Yes, ideally it would be encrypted as well.
Single quotes are now dealt with in CVS.
Fixed package is 0.4.1-1.