[Samba] how to mount shares as a user without mount.cifs setuid
Gary Dale
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?
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
Udo Müller
> 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
Jeff Layton
Gary Dale <gary...@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 <jla...@samba.org>
Gary Dale
mount.cifs not being setuid. This is generated from the user option in
fstab. If I remove the user option, I am told that only root can mount
the share. Thus my problem that normal users cannot mount smbfs/cifs
shares. This appears to be reserved now only for root.
> 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.
>
I would except that Debian/Squeeze has its own repositories that I'd
prefer to stick with. Hopefully they'll catch up shortly.
While the ability to run mount.cifs setuid again is appreciated, how
does that fit in with the "horribly unsecure" reasoning that led to it
being removed?
Chris Smith
> 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.
Christian PERRIER
> 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.
cifs-utils 4.2 has yet to be packaged for Debian
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576314).
Will we decide to re-enable setuid? We already have a bug report
asking for this..:-)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576713
Jeff Layton
Chris Smith <smb...@chrissmith.org> wrote:
> On Wed, Apr 7, 2010 at 9:39 PM, Jeff Layton <jla...@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.
>
Our hand was forced. After repeatedly telling people who were
installing it setuid root "don't do that", we continued to get CVE's
reported from people who continued to use it that way and expected us
to treat the problem as a security issue.
Our fix was somewhat heavy-handed, but we absolutely had to make it
clear that it wasn't safe to install mount.cifs in that fashion. The
patch to remove that check was trivial (simply change one #define in
the code), but required the person building the program to
consciously override our warnings. The Debian package maintainer
wisely chose not to do so.
In any case, the point is somewhat moot now. The current mount.cifs
that ships in cifs-utils no longer prevents installation as a setuid
root program.
--
Jeff Layton <jla...@samba.org>
Nico Kadel-Garcia
> On Wed, Apr 7, 2010 at 9:39 PM, Jeff Layton <jla...@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.
It doesn't stop a sysadmin. Sysadmins have root privileges and do not
need setuid for this. Sysadmins can also manipulate automount or
/etc/fstab to allow far more controlled mounting.
This isn't "handcuffs". It's a seatbelt.
Jeff Layton
Gary Dale <gary...@rogers.com> wrote:
> Jeff Layton wrote:
> > On Wed, 07 Apr 2010 16:44:47 -0400
> > Gary Dale <gary...@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.
> >
> Except that when I run mount as a non-root user, I get the error about
> mount.cifs not being setuid. This is generated from the user option in
> fstab. If I remove the user option, I am told that only root can mount
> the share. Thus my problem that normal users cannot mount smbfs/cifs
> shares. This appears to be reserved now only for root.
>
Sorry, I should have been more clear. The uid=/gid= options will just
fix the ownership issues if you do the mount as root. It won't allow the
mount to be performed by a non-privileged user.
> > 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.
> >
> I would except that Debian/Squeeze has its own repositories that I'd
> prefer to stick with. Hopefully they'll catch up shortly.
>
> While the ability to run mount.cifs setuid again is appreciated, how
> does that fit in with the "horribly unsecure" reasoning that led to it
> being removed?
The code has been substantially reworked and should be far safer than
it was previously. It does privilege separation now such that the bulk
of the mount process is performed as an unprivileged user, and if
linked against the right libs, with capabilities pruned to the minimum.
At this point, I'd say it's safe enough that we no longer need to
restrict it from being installed setuid root. As always, you should
weigh carefully whether to do so in your own environment and packages.
FWIW, I have no plans to make the Fedora cifs-utils package install
mount.cifs setuid root. Part of the reason for that is that no one has
requested it.
--
Jeff Layton <jla...@samba.org>
Gary Dale
> On Thu, Apr 8, 2010 at 12:45 AM, Chris Smith <smb...@chrissmith.org> wrote:
>
>> On Wed, Apr 7, 2010 at 9:39 PM, Jeff Layton <jla...@samba.org> wrote:
>>
>>> 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.
>>>
>> 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.
>>
>
> It doesn't stop a sysadmin. Sysadmins have root privileges and do not
> need setuid for this. Sysadmins can also manipulate automount or
> /etc/fstab to allow far more controlled mounting.
>
> This isn't "handcuffs". It's a seatbelt.
>
to mount their own shares, they can do it. If I set up fstab to mount
shares as root using specific uid and gid values, then the users don't
see their correct permissions. That's a straightjacket, not a seatbelt.
Now perhaps I'm missing something, but I have no trouble with users
mounting nfs shares. The idea that users can't mount cifs shares strikes
me as odd and an unnecessary impediment.
Christian PERRIER
> Now perhaps I'm missing something, but I have no trouble with users
> mounting nfs shares. The idea that users can't mount cifs shares
> strikes me as odd and an unnecessary impediment.
How about turning the binary we provide in Debian to setuid on the
systems where you want it to be this way, by using
dpkg-statoverride(8)?
Gary Dale
> Quoting Gary Dale (gary...@rogers.com):
>
>
>> Now perhaps I'm missing something, but I have no trouble with users
>> mounting nfs shares. The idea that users can't mount cifs shares
>> strikes me as odd and an unnecessary impediment.
>>
>
> How about turning the binary we provide in Debian to setuid on the
> systems where you want it to be this way, by using
> dpkg-statoverride(8)?
>
setuid is a seatbelt. The idea that mounting shares should be restricted
to root is, imho, a cure that is worse than the disease. :)
Nico Kadel-Garcia
> Christian PERRIER wrote:
>>
>> Quoting Gary Dale (gary...@rogers.com):
>>
>>
>>>
>>> Now perhaps I'm missing something, but I have no trouble with users
>>> mounting nfs shares. The idea that users can't mount cifs shares
>>> strikes me as odd and an unnecessary impediment.
>>>
>>
>> How about turning the binary we provide in Debian to setuid on the
>> systems where you want it to be this way, by using
>> dpkg-statoverride(8)?
>>
>
> Actually, I was just responding to Nico's assertion that disabling setuid is
> a seatbelt. The idea that mounting shares should be restricted to root is,
> imho, a cure that is worse than the disease. :)
It's safer *default* behavior. If you want non-root users to be able
to mount, you can create a table of mounting options in auto.master or
in another auto.cifs file that will translate the mounting options
into something available to users, with wildcards to allow access to
alternative servers or shares.
Gary Dale
> On Thu, Apr 8, 2010 at 2:08 PM, Gary Dale <gary...@rogers.com> wrote:
>
>> Christian PERRIER wrote:
>>
>>> Quoting Gary Dale (gary...@rogers.com):
>>>
>>>
>>>
>>>> Now perhaps I'm missing something, but I have no trouble with users
>>>> mounting nfs shares. The idea that users can't mount cifs shares
>>>> strikes me as odd and an unnecessary impediment.
>>>>
>>>>
>>> How about turning the binary we provide in Debian to setuid on the
>>> systems where you want it to be this way, by using
>>> dpkg-statoverride(8)?
>>>
>>>
>> Actually, I was just responding to Nico's assertion that disabling setuid is
>> a seatbelt. The idea that mounting shares should be restricted to root is,
>> imho, a cure that is worse than the disease. :)
>>
>
> It's safer *default* behavior. If you want non-root users to be able
> to mount, you can create a table of mounting options in auto.master or
> in another auto.cifs file that will translate the mounting options
> into something available to users, with wildcards to allow access to
> alternative servers or shares.
>
following the howto at
http://www.howtoforge.com/accessing_windows_or_samba_shares_using_autofs.
I installed autofs v5.0.4 from the Debian/Squeeze repository and created
the /etc/auto.cifs file. I made it executable and changed the mountopts
line to:
mountopts="-fstype=cifs,file_mode=0644,dir_mode=0755,uid=garydale,gid=users".
I created a /etc/auto.smb.<filesever> file and gave it my credentials.
Then I added the auto.cifs line to the auto.master file and restarted
the autofs system.
I then fixed a few errors I was getting re. my domain name by adding an
automount: nis files line to /etc/nsswitch.conf and also running
domainname <mydomain>.
At this point I can run ls -als /cifs/<fileserver> and see all the
exported shares, etc. from that server. However the shares are not
mounted. Checking syslog I now find an error "Status code returned
0xc000005e NT_STATUS_NO_LOGON_SERVERS".
Google only finds two hits on this message, neither of which was
helpful. I know my Windows desktops are logging in to the domain as
their profiles are updated when they do.
Anyway, this leaves me with some questions.
1) do you have any idea on how to fix the error?
2) even if I do, I think I need more information on how auto.cifs can
help. If I replace the uid=garydale with something like uid=$USER, won't
that just pick up the uid as root, the context in which the mount is
running?
3) the credentials file for autofs seems to only allow a single
username+password combo for each mount. Is there a way around this?
4) can the credentials be updated automatically when the user changes
their password?