Description of problem: Can't mount cifs shares with credentials files. Version-Release number of selected component (if applicable): 3.0.33-0.18.el4_8 How reproducible: Steps to Reproduce: 1. fstab entry along the lines of //server/share /mnt/point cifs user,credentials=/credfile,rw,noauto 0 0 2. chmod +s /sbin/mount.cifs 3. chmod +s /sbin/umount.cifs 4. mount //server/share Actual results: mount error 13 = Permission denied Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) Expected results: share should mount. It did before the paych was installed. Additional info: Could mount from command line after removing "credentials=/credfile" from /etc/fstab. I was then prompted for password. But, if I added "-o password=" to command line, got "only root can do that" Got same error as above when "credentials=/credfile" was in /etc/fstab and tried mount //server/share as root. I note that part of the patch addressed handling of credentials files. Was it botched?
What are the permissions on /credfile?
u=rw,g=,o= I tried pointing to non-existant files and got a different error message. I also tried more generous permissions with same result as above. I also tried to mount as root and that did not help (even if I changed the group of the cred file to root and made it readable to that group)
Do you happen to know what version of the samba-client package you had installed before patching? I'm having some trouble getting credentials files to work too. The problem is that vim was adding a trailing newline to the password and mount.cifs isn't stripping that out. I'll see about doing a patch to fix that. The thing is that that doesn't appear to be a regression unless I'm missing something. Also, FWIW there are some serious security issues with installing mount.cifs setuid root. We highly recommend that it not be installed and used that way.
This is a system that is regularly updated via up2date. So, it was using the version immediately prior to the one just released (and named in the bug report). Thanks for the advice on the security risk. I'd like not to do this, but am faced with a bit of a dilemma. The server is effectively doing a backup from one samba share to another as a cron job. I'd rather not have the backup run as root and would rather not leave the shares mounted on a permanent basis. Can you recommend an alternative to running mount.cifs as suid? Of course, even if I mount as root at boot time, I still want to use credentials files (and I assume there are lots of other folks who would like to use them too). So, we still need a patch to fix this problem. As a quick fix, can I simply edit out the trailing new line from the credentials file?
(In reply to comment #4) > Thanks for the advice on the security risk. I'd like not to do this, but am > faced with a bit of a dilemma. The server is effectively doing a backup from > one samba share to another as a cron job. I'd rather not have the backup run > as root and would rather not leave the shares mounted on a permanent basis. > Can you recommend an alternative to running mount.cifs as suid? > No real recommendation... Maybe sudo with NOPASSWD for your backup user? That's probably safer than having mount.cifs installed setuid root. > Of course, even if I mount as root at boot time, I still want to use > credentials files (and I assume there are lots of other folks who would like to > use them too). So, we still need a patch to fix this problem. > > As a quick fix, can I simply edit out the trailing new line from the > credentials file? Yeah, I'm planning to fix it, but I'll probably need to push a patch to the upstream mount.cifs. I still want to understand why this broke with the latest update though. I'll look a little more closely when I get some time. Assuming that the problem you're having and this problem are the same then yes, removing the newline after the "password=" line should work around the problem. Note that I haven't tried that though so please post the results here if that works.
Created attachment 367006 [details] patch -- fix up newlines in parsing routines This patch seems to fix the problem. I converted the parsing routines to match upstream, but missed these patches when backporting.
The corresponding bug report for RHEL 5 is https://bugzilla.redhat.com/show_bug.cgi?id=532153 .
Event posted on 11-05-2009 02:42pm EST by jpayne I have created test packages using the patch attached to 532094. Please have the customer test them, and report back to us. Test packages can be found at: http://people.redhat.com/jpayne/361510/ Internal Status set to 'Waiting on Support' This event sent from IssueTracker by jpayne issue 361510
Sorry folks. I was out sick all week last week. I will try to get this tested in the next couple of days.
This bug caused a problem with some of my backups. A quick workaround for this problem is to comma-delimit the domain, username, and password in the credentials file. For example, change your credentials file from domain=yourdomain.com\n username=yourusername\n password=yourpassword\n to domain=yourdomain.com,username=yourusername,password=yourpassword Then, change your mount command from mount -t cifs -o credentials=/credfile //server/share /mnt/point to mount -t cifs -o `cat /credfile` //server/share /mnt/point
(In reply to comment #13) > This bug caused a problem with some of my backups. A quick workaround for this > problem is to comma-delimit the domain, username, and password in the > credentials file. For example, change your credentials file from > > domain=yourdomain.com\n > username=yourusername\n > password=yourpassword\n > > to > > domain=yourdomain.com,username=yourusername,password=yourpassword > > > Then, change your mount command from > > mount -t cifs -o credentials=/credfile //server/share /mnt/point > > to > > mount -t cifs -o `cat /credfile` //server/share /mnt/point This does indeed work. Perhaps the manpage should be updated to match? (A separate ticket, so as not to hold this up any longer?) With this work-around I'm going to have one less angry/annoyed customer tomorrow morning.
No this should never go into a manpage. It is a temporary workaround and dangerous too, the point of a credentials file is also to make sure that credentials are not accessible to users. If you do `cat /credfile` you are basically exposing your credentials in clear text for the whole time the "mount" command is running as they will be available in /proc as the cmdline for that command. Any user can easily see them with a ps, if they happen to ps at the moment mount is running, which can also be a relatively long time given network traffic is involved when dealing with mount.cifs
Event posted on 11-12-2009 12:03pm EST by jpayne Test packages can be found at: http://people.redhat.com/jpayne/361510/ This event sent from IssueTracker by jpayne issue 361518
(In reply to comment #15) > No this should never go into a manpage. > It is a temporary workaround and dangerous too, the point of a credentials file > is also to make sure that credentials are not accessible to users. > > If you do `cat /credfile` you are basically exposing your credentials in clear > text for the whole time the "mount" command is running as they will be > available in /proc as the cmdline for that command. > > Any user can easily see them with a ps, if they happen to ps at the moment > mount is running, which can also be a relatively long time given network > traffic is involved when dealing with mount.cifs How long does it really take for the mount command to run? Just a few milliseconds for me. In a secure environment where few users have access to a shell, I'm willing to take the statistically minuscule chance that somebody could access the account password so I can get a good backup.
(In reply to comment #15) > No this should never go into a manpage. > It is a temporary workaround and dangerous too, the point of a credentials file > is also to make sure that credentials are not accessible to users. > > If you do `cat /credfile` you are basically exposing your credentials in clear > text for the whole time the "mount" command is running as they will be > available in /proc as the cmdline for that command. > > Any user can easily see them with a ps, if they happen to ps at the moment > mount is running, which can also be a relatively long time given network > traffic is involved when dealing with mount.cifs I'll agree with you that the information is available on the command line where in theory it shouldn't be. What I thought I was talking about was the format of the cred file being fleshed out a bit more. Apparently I spoke out of turn. (Besides, I'd be more worried about users running 'top' as ps can be a hit or miss thing sometimes for shorter-lived processes.) IN any case, leaving system administrators without quick reminders of work-arounds is also a very bad situation and merely noting that in an emergency you can do "x,y, and z" with a "black box" severity warning does not sound out of line to me. We all have too much to think about daily to remember instantly all of the ways to hold out until a fix comes available. (Especially when another bug with the same package makes reverting the packages a potentially painful and messy process.) A simple "This does the same thing as cat'ing the contents of a comma-delimited credentials file into the body of the command line but does not suffer from the associated security implications," added to the manpage would suffice--and would serve as a good reminder of best practices as well (often sorely lacking from the manpages). (In reply to comment #16) > Test packages can be found at: > > http://people.redhat.com/jpayne/361510/ If we install the test package will it be cleanly upgraded over? Considering the oops in the latest samba-common package (518785) I'd prefer not to have to do manual cleanup after a newer version comes out.
(In reply to comment #9) > Test packages can be found at: > > http://people.redhat.com/jpayne/361510/ Please provide src.rpm there. Required both for good security practice, and for compliance with GPL.
The source for samba-3.0.33-0.18.el4_8 is provided via Red Hat Network. The patch source is attached to this bugzilla.
> (In reply to comment #16) > > Test packages can be found at: > > > > http://people.redhat.com/jpayne/361510/ > > If we install the test package will it be cleanly upgraded over? Considering > the oops in the latest samba-common package (518785) I'd prefer not to have to > do manual cleanup after a newer version comes out. These packages were built with the stock 3.0.33-0.18.el4_8 spec file, and still contain "restorecon %{_sysconfdir}/samba/secrets.tdb" in the %post common section.
I have (finally) tested the patch described above and it appears to solve my problems with credentials files. Please note that our use of the samba packages is fairly limited and low intensity.
(In reply to comment #20) > The source for samba-3.0.33-0.18.el4_8 is provided via Red Hat Network. Just for the record, AIUI the Red Hat Network is not sufficient (for GPL compliance, when you make binary test packages available via anonymous http). It's not freely available to everyone who can obtain the binaries. > The patch source is attached to this bugzilla. The build instructions are also necessary - i.e. the spec file in this case. If you provide the SRPM, the patch and spec file are included as a matter of course.
Charlie, As of today, not only samba-3.0.33-0.18.el4_8.src.rpm is available from the public Red Hat ftp site but the current version samba-3.0.33-0.19.el4_8.3.src.rpm is there. :)
(In reply to comment #29) > As of today, not only samba-3.0.33-0.18.el4_8.src.rpm is available from the > public Red Hat ftp site but the current version > samba-3.0.33-0.19.el4_8.3.src.rpm is there. :) That's all well and good, but not relevant. My comments referred to the binaries that were made available via http://people.redhat.com/jpayne/361510/ in comment #16. My comment was "just for the record". Pointing to RHN to the source code to some similar package does not satisfy the GPL. Neither does pointing to a patch.
(In reply to comment #30) > (In reply to comment #29) > > > As of today, not only samba-3.0.33-0.18.el4_8.src.rpm is available from the > > public Red Hat ftp site but the current version > > samba-3.0.33-0.19.el4_8.3.src.rpm is there. :) > > That's all well and good, but not relevant. My comments referred to the > binaries that were made available via http://people.redhat.com/jpayne/361510/ > in comment #16. My comment was "just for the record". Pointing to RHN to the > source code to some similar package does not satisfy the GPL. Neither does > pointing to a patch. Duly noted. FWIW, it was an honest mistake. The comment was auto posted by our ticketing system, and was never meant to be a public comment. Had things worked out properly, only the customer they were intended for would have had access to them for testing purposes. I will try to be more diligent next time.
(In reply to comment #31) > Duly noted. FWIW, it was an honest mistake. No accusation intended. > The comment was auto posted by our > ticketing system, and was never meant to be a public comment. Had things worked > out properly, only the customer they were intended for would have had access to > them for testing purposes. I don't agree. If things had worked out properly, any of us could have reviewed and tested your fix. I don't see how it would help anyone for you to make that process private.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Due to faulty parsing routines, an attempt to mount a CIFS (Common Internet File System) share with credentials files specified failed. The parsing routines were fixed and mounting CIFS shares works as expected.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0242.html