All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: "Milan Knížek" <knizek.confy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: mount.cifs multiuser w/o krb5? How?
Date: Fri, 6 Jul 2012 14:15:43 -0400	[thread overview]
Message-ID: <20120706141543.1b564c11@tlielax.poochiereds.net> (raw)
In-Reply-To: <1341427937.3252.6.camel-77nuZImz6nKt3pJmeLR6bw@public.gmane.org>

On Wed, 04 Jul 2012 20:52:17 +0200
Milan Knížek <knizek.confy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Hello,
> 
> I would like to have a single cifs mount accessible by multiple users
> allowing them to create files with their respective uid.
> 
> Having spent some time on RTFM and Google search on this mailing list,
> it seems that the "multiuser" option of mount.cifs could make me happy.
> And it should work now also for systems w/o krb5.
> 
> 
> My intention is to avoid use of any directory services or domain (small
> network of mainly linux clients). The test platform (both server and
> client) are Arch linux, kernel 3.4.4-2-ARCH x86-64, cifs-utils 5.4-1.
> 

Thanks for giving this a go. It's quite new, so there may be some kinks
to work out. Those cifs-utils and kernel versions should be fine for
this.

> The smb.conf on the server has
> security = user
> client ntlmv2 auth = yes
> 
> I can post full smb.conf, if needed. Users have the same uid on both
> client and server.
> 
> From the client, I am able to mount - as root - //server/share with
> credentials of user1 and user1 can access the share. Mounting and
> accessing works also for user2.
> 
> [root@client /]$ mount
> //server/share on /mnt type cifs (rw,relatime,sec=ntlmv2,unc=\\server
> \share,username=user1,domain=WORKGROUP,uid=0,noforceuid,gid=0,
> noforcegid,addr=192.168.1.3,unix,posixpaths,serverino,acl,
> rsize=1048576,wsize=65536,actimeo=1
> 
> To move on for multiuser: adding the credentials to the keyring:
> [user1@client /]$ cifscreds add server
> and typing in the password.
> 
> (Similarly for user2.)
> 
> When I remount the same share with "multiuser" option with the
> credentials of user1, the share is accessible only by the root user, the
> users user1 and user2 cannot list the mount point (cannot access /mnt:
> Permission denied)
> 

Can you clarify exactly what you did above? How, exactly did you
remount the share?

> What do I do wrong?
> 
> Adding cifscreds has exit code 0. Running "cifscreds clearall" results
> in "You have no stashed cifs credentials. If you want to add them use:
> cifscreds add" and exit code 1. That's weird.
> 

After you do the "cifscreds add", if you then do a "keyctl show" does
it show the cifs keys attached to your session keyring?

One thing that may be biting you: cifscreds attaches the keys to the
session keyring. If you do the "add" in one session and then try to
access from another, it won't work since the keys just aren't present.
The fact that "clearall" doesn't find any creds leads me to suspect
that's what's going on here.

The scope of a "session" in keys parlance is unfortunately somewhat
poorly defined, but you basically need to do the "cifscreds add" from
each login. A graphical login on the console would be a single session
however.

> The manpage of cifscreds reads "The cifscreds utility requires a kernel
> built with support for the login key type." What is the name of kernel
> config option to check?
> 

There's no specific configuration. Newer kernels should all get the "login"
key type as it's part of the "core" keys API.

> Further it reads "When a cifs filesystem is mounted with the "multiuser"
> option, and does not use krb5 authentication, it needs to be able to get
> the credentials for each user from somewhere. The cifscreds program is
> the tool used to provide these credentials to the kernel."
> 
> However, man page of mount.cifs mentions "Because the kernel cannot
> prompt for passwords, multiuser mounts are limited to mounts using sec=
> options that don't require passwords." Does that include NTLMv2 or its
> variants? Do I have to do something extra to let the kernel know about
> the credentials?
> 

The cifscreds manpage is correct, and the mount.cifs one probably needs
updating.

-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

  parent reply	other threads:[~2012-07-06 18:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-04 18:52 mount.cifs multiuser w/o krb5? How? Milan Knížek
     [not found] ` <1341427937.3252.6.camel-77nuZImz6nKt3pJmeLR6bw@public.gmane.org>
2012-07-06 18:15   ` Jeff Layton [this message]
     [not found]     ` <20120706141543.1b564c11-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2012-07-06 22:09       ` Milan Knížek
     [not found]         ` <1341612593.26748.9.camel-77nuZImz6nKt3pJmeLR6bw@public.gmane.org>
2012-07-09 10:26           ` Jeff Layton
2012-07-10 21:01             ` knizek-VIXq6x/3rUk
2012-07-10 21:05             ` knizek-VIXq6x/3rUk
2012-07-11 19:05 Milan Knížek
2012-07-11 19:56 ` Jeff Layton
2012-07-11 19:06 Milan Knížek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120706141543.1b564c11@tlielax.poochiereds.net \
    --to=jlayton-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=knizek.confy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.