samba - Apr 2010 - how to mount shares as a user without mount.cifs setuid

I'm running Debian/Squeeze on an AMD64 system. For some reason they have 
recently stopped shipping mount.cifs with the setuid bit set. Now it 
appears that they have changed the internal settings to prevent it from 
running setuid. This means that I can't define the share in fstab with 
"user" and connect from my Linux user account. Mounting smb/cifs
shares
seems to be blocked except for root.

Presumably this has been done for security reasons. However, I can't 
currently do much with my network shares unless I'm root because the 
shares and all the files are owned by root:root. This is despite the 
fstab setting username=<my windows account name> and I get prompted for 
the password. That only seems to be used for connecting to the share, 
not for the permissions.

My Debian box hasn't joined a domain - I'm just using local accounts. I 
mainly have the domain for some Windows boxes used by my family.

How do I mount an smb/cifs share as a normal user without running 
mount.cifs? Or if I have to mount the share as root, how can I get 
reasonable access to the shares?

Am 07.04.10 22:44, schrieb Gary Dale:
> How do I mount an smb/cifs share as a normal user without running
> mount.cifs? Or if I have to mount the share as root, how can I get
> reasonable access to the shares?
Use FUSE.

Regards Udo

On Wed, 07 Apr 2010 16:44:47 -0400
Gary Dale <garydale at rogers.com> wrote:
> I'm running Debian/Squeeze on an AMD64 system. For some reason they
have
> recently stopped shipping mount.cifs with the setuid bit set.
That would be because it was horribly unsecure.
>  Now it 
> appears that they have changed the internal settings to prevent it from 
> running setuid. This means that I can't define the share in fstab with 
> "user" and connect from my Linux user account. Mounting smb/cifs
shares
> seems to be blocked except for root.
> 
Yes, we added a patch a while back to make it such that mount.cifs
would not allow itself to run as a setuid root program unless it that
check was compiled out.

This was done due to a rather constant stream of "security issues"
that
were brought about when people installed mount.cifs setuid root. Since
it had never been vetted for security, we really had no other choice to
communicate that installing it setuid root was unsafe.
> Presumably this has been done for security reasons. However, I can't 
> currently do much with my network shares unless I'm root because the 
> shares and all the files are owned by root:root. This is despite the 
> fstab setting username=<my windows account name> and I get prompted
for
> the password. That only seems to be used for connecting to the share, 
> not for the permissions.
> 
> My Debian box hasn't joined a domain - I'm just using local
accounts. I
> mainly have the domain for some Windows boxes used by my family.
> 
> How do I mount an smb/cifs share as a normal user without running 
> mount.cifs? Or if I have to mount the share as root, how can I get 
> reasonable access to the shares?
> 
You need to set the uid=/gid= options when mounting. When it's run by a
non-root user, /bin/mount adds these options automatically.

It's also worthwhile to note that I've recently re-enabled the ability
to run mount.cifs as a setuid root program in the latest cifs-utils
release:

http://linux-cifs.samba.org/cifs-utils/

...you may want to switch to using that instead if you need the ability
to use mount.cifs in this way.

-- 
Jeff Layton <jlayton at samba.org>

On Wed, Apr 7, 2010 at 9:39 PM, Jeff Layton <jlayton at samba.org>
wrote:
> Yes, we added a patch a while back to make it such that mount.cifs
> would not allow itself to run as a setuid root program unless it that
> check was compiled out.
>
> This was done due to a rather constant stream of "security
issues" that
> were brought about when people installed mount.cifs setuid root. Since
> it had never been vetted for security, we really had no other choice to
> communicate that installing it setuid root was unsafe.
Not the place for it so the inquiry is only rhetorical.
How can you equate adding a patch preventing a sysadmin from using an
app as designed to communicating? Communication is one thing,
handcuffs are another.