How to mount a CIFS file system as a user?
I want a simple way to mount a CIFS file system that I can run as a user. There seems to be considerable confusion between the mount man page and the mount.cifs man page as to what can be done and what can't be done. According to the mount man page I can add a line to /etc/fstab as follows (or something like, the syntax may well be wrong) :- //192.168.1.10/C /home/chris/xp cifs noauto,user 0 0 The 'user' option is supposed to allow a user to mount the file system. However if I say "mount /home/chris/xp" I get:- mount error 1 = Operation not permitted Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) Referring to the mount.cifs(8) manual page as requested is not very enlightening! Running "mount /home/chris/xp" as root works (I have to admit I only just tried) so the entry in /etc/fstab must be about right. -- Chris Green
Chris G <cl@isbd.net> wrote:
Referring to the mount.cifs(8) manual page as requested is not very enlightening!
The user option on there is rather different to the one on mount(8): user=arg specifies the username to connect as. [...] I think you may have to set user=... and then override it if you want, which is odd. I wonder if the namespace collision is intentional. Hope that helps, -- MJ Ray http://mjr.towers.org.uk/email.html tel:+44-844-4437-237 - Webmaster-developer, statistician, sysadmin, online shop builder, consumer and workers co-operative member http://www.ttllp.co.uk/ - Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/
On Wed, Oct 17, 2007 at 09:37:55PM +0100, MJ Ray wrote:
Chris G <cl@isbd.net> wrote:
Referring to the mount.cifs(8) manual page as requested is not very enlightening!
The user option on there is rather different to the one on mount(8):
user=arg specifies the username to connect as. [...]
I think you may have to set user=... and then override it if you want, which is odd. I wonder if the namespace collision is intentional.
There are a few references to this if you do a Google search. It turns out that the easy way to get it to work is to set the SUID bit on /sbin/mount.cifs and /sbin/umount.cifs, it now works for me. -- Chris Green
On Wed, 2007-10-17 at 22:01 +0100, Chris G wrote:
There are a few references to this if you do a Google search.
It turns out that the easy way to get it to work is to set the SUID bit on /sbin/mount.cifs and /sbin/umount.cifs, it now works for me.
Does that not leave the system quite vulnerable ? If you suid mount commands couldn't I (as a user) now copy /etc to a cifs share someplace, change passwd and then mount it back over your /etc to gain root ? Or am I missing something that would prevent that from working ?
On Thu, Oct 18, 2007 at 02:16:09AM +0100, Wayne Stallwood wrote:
On Wed, 2007-10-17 at 22:01 +0100, Chris G wrote:
There are a few references to this if you do a Google search.
It turns out that the easy way to get it to work is to set the SUID bit on /sbin/mount.cifs and /sbin/umount.cifs, it now works for me.
Does that not leave the system quite vulnerable ?
If you suid mount commands couldn't I (as a user) now copy /etc to a cifs share someplace, change passwd and then mount it back over your /etc to gain root ?
Or am I missing something that would prevent that from working ?
It does say (in some of the places where it suggests it) that one must have an environment where users are trusted. Since my environment is just me all I need to protect against is my stupidity/fallibility. In addition the /etc/shadow file shouldn't be readable to anyone except root and so won't get copied if you copy /etc, I expect there may be other files in /etc that aren't world readable for the same reason. -- Chris Green
On Thu, 2007-10-18 at 08:43 +0100, Chris G wrote:
It does say (in some of the places where it suggests it) that one must have an environment where users are trusted. Since my environment is just me all I need to protect against is my stupidity/fallibility.
I figured that, I just thought it was worth mentioning why this may not be best practise in case somebody else follows this advice.
In addition the /etc/shadow file shouldn't be readable to anyone except root and so won't get copied if you copy /etc, I expect there may be other files in /etc that aren't world readable for the same reason.
That doesn't really matter though does it ? There is nothing as far as I know stopping you from rewriting the passwd file legacy style with password hashes for known passwords. In fact I think it is probably possible to have a mix of these and passwd entries that reference the shadow file. As to the other read only stuff, there is probably nothing that would prevent the system working well enough for someone to login. Even if the login mechanism forced you to use shadow passwords it would only mean that as soon as you do the mount your version all other logins would fail. In a situation where the sysadmin doesn't have immediate physical access to the box in question this may actually be an advantage to an intruder in some scenarios.
On Thu, Oct 18, 2007 at 10:53:57AM +0100, Wayne Stallwood wrote:
On Thu, 2007-10-18 at 08:43 +0100, Chris G wrote:
It does say (in some of the places where it suggests it) that one must have an environment where users are trusted. Since my environment is just me all I need to protect against is my stupidity/fallibility.
I figured that, I just thought it was worth mentioning why this may not be best practise in case somebody else follows this advice.
In addition the /etc/shadow file shouldn't be readable to anyone except root and so won't get copied if you copy /etc, I expect there may be other files in /etc that aren't world readable for the same reason.
That doesn't really matter though does it ? There is nothing as far as I know stopping you from rewriting the passwd file legacy style with password hashes for known passwords. In fact I think it is probably possible to have a mix of these and passwd entries that reference the shadow file. As to the other read only stuff, there is probably nothing that would prevent the system working well enough for someone to login.
In that case what is the point of the shadow file? I suppose it stops simple 'brute force' methods of guessing passwords but, if what you say is true, that would seem to be all.
Even if the login mechanism forced you to use shadow passwords it would only mean that as soon as you do the mount your version all other logins would fail. In a situation where the sysadmin doesn't have immediate physical access to the box in question this may actually be an advantage to an intruder in some scenarios.
But in this case the intruder wouldn't be root would they, and they wouldn't be able to become root. However it's all fairly academic in my situation though it does mean that the (few) user passwords should be good/secure as the box does have ssh access from the outside world. I have in fact been wondering whether to tie it down even more tightly by restricting ssh access to a few known IP addresses. One of these allowed IP addresses can then be my hosting provider where I have ssh access so, if I want to get into my system from somewhere else, I could log in to my account on my hosting provider and then to my home system. However looking at my system logs shows very few attempts to login using ssh, like a dozen or so a day, and they use only very obvious user IDs. -- Chris Green
On Thu, Oct 18, 2007 at 11:33:08AM +0100, Chris G wrote:
On Thu, Oct 18, 2007 at 10:53:57AM +0100, Wayne Stallwood wrote:
On Thu, 2007-10-18 at 08:43 +0100, Chris G wrote:
It does say (in some of the places where it suggests it) that one must have an environment where users are trusted. Since my environment is just me all I need to protect against is my stupidity/fallibility.
I figured that, I just thought it was worth mentioning why this may not be best practise in case somebody else follows this advice.
In addition the /etc/shadow file shouldn't be readable to anyone except root and so won't get copied if you copy /etc, I expect there may be other files in /etc that aren't world readable for the same reason.
That doesn't really matter though does it ? There is nothing as far as I know stopping you from rewriting the passwd file legacy style with password hashes for known passwords. In fact I think it is probably possible to have a mix of these and passwd entries that reference the shadow file. As to the other read only stuff, there is probably nothing that would prevent the system working well enough for someone to login.
In that case what is the point of the shadow file? I suppose it stops simple 'brute force' methods of guessing passwords but, if what you say is true, that would seem to be all.
It stops users from being able to use cracking utilities over the passwords in the passwd file, IIRC you can't actually mix shadow with a passwd file containing passwords. It can be set with very minimum permissions because the only thing that should be able to read it is pam or a root user. (But, yes, if there isn't a shadow file, and the password file includes passwords, that's all that's needed).
Even if the login mechanism forced you to use shadow passwords it would only mean that as soon as you do the mount your version all other logins would fail. In a situation where the sysadmin doesn't have immediate physical access to the box in question this may actually be an advantage to an intruder in some scenarios.
But in this case the intruder wouldn't be root would they, and they wouldn't be able to become root.
They'd mount /etc from CIFS with a blank or known root password in the /etc/password file, then they could become root, swivel things about a bit, and do anything they please. Anyways... I'm hungry so off to get lunch :) -- Brett Parker
On 10/18/07, Chris G <cl@isbd.net> wrote:
However looking at my system logs shows very few attempts to login using ssh, like a dozen or so a day, and they use only very obvious user IDs.
Only a dozen? Crikey! In a day I typically get between 1 and 5 attempt runs. If left unchecked each attempt run will try many, many obvious user names and passwords for about an hour. I run a blocking tool which inserts a DROP entry in the IP tables after 4 bad user names. The IP address is automatically unblocked after about ten days. Tim.
participants (5)
-
Brett Parker -
Chris G -
MJ Ray -
Tim Green -
Wayne Stallwood