Nabble - Samba - linux-cifs-client

[PATCH] cifs: don't use CIFSGetSrvInodeNumber in is_path_accessible

2009-11-08T16:39:04Z

Because it's lighter weight, CIFS tries to use CIFSGetSrvInodeNumber to
verify the accessibility of the root inode and then falls back to doing a
full QPathInfo if that fails with -EOPNOTSUPP. I have at least a report
of a server that returns NT_STATUS_INTERNAL_ERROR rather than something
that translates to EOPNOTSUPP.

Rather than trying to be clever with that call, just have
is_path_accessible do a normal QPathInfo. That call is widely
supported and it shouldn't increase the overhead significantly.

Cc: Stable <stable@...>
Signed-off-by: Jeff Layton <jlayton@...>
Signed-off-by: Steve French <sfrench@...>
---
fs/cifs/connect.c | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index b090980..63ea83f 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -2220,16 +2220,8 @@ is_path_accessible(int xid, struct cifsTconInfo *tcon,
struct cifs_sb_info *cifs_sb, const char *full_path)
{
int rc;
- __u64 inode_num;
FILE_ALL_INFO *pfile_info;

- rc = CIFSGetSrvInodeNumber(xid, tcon, full_path, &inode_num,
- cifs_sb->local_nls,
- cifs_sb->mnt_cifs_flags &
- CIFS_MOUNT_MAP_SPECIAL_CHR);
- if (rc != -EOPNOTSUPP)
- return rc;
-
pfile_info = kmalloc(sizeof(FILE_ALL_INFO), GFP_KERNEL);
if (pfile_info == NULL)
return -ENOMEM;
--
1.6.0.6

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[PATCH] cifs: clean up handling when server doesn't consistently support inode numbers

2009-11-08T16:39:03Z

It's possible that a server will return a valid FileID when we query the
FILE_INTERNAL_INFO for the root inode, but then zeroed out inode numbers
when we do a FindFile with an infolevel of
SMB_FIND_FILE_ID_FULL_DIR_INFO.

In this situation turn off querying for server inode numbers, generate a
warning for the user and just generate an inode number using iunique.
Once we generate any inode number with iunique we can no longer use any
server inode numbers or we risk collisions, so ensure that we don't do
that in cifs_get_inode_info either.

Cc: Stable <stable@...>
Reported-by: Timothy Normand Miller <theosib@...>
Signed-off-by: Jeff Layton <jlayton@...>
Signed-off-by: Steve French <sfrench@...>
---
fs/cifs/cifsproto.h | 1 +
fs/cifs/inode.c | 7 ++-----
fs/cifs/misc.c | 14 ++++++++++++++
fs/cifs/readdir.c | 7 ++++---
4 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/fs/cifs/cifsproto.h b/fs/cifs/cifsproto.h
index 6928c24..5646727 100644
--- a/fs/cifs/cifsproto.h
+++ b/fs/cifs/cifsproto.h
@@ -388,4 +388,5 @@ extern int CIFSSMBSetPosixACL(const int xid, struct cifsTconInfo *tcon,
const struct nls_table *nls_codepage, int remap_special_chars);
extern int CIFSGetExtAttr(const int xid, struct cifsTconInfo *tcon,
const int netfid, __u64 *pExtAttrBits, __u64 *pMask);
+extern void cifs_autodisable_serverino(struct cifs_sb_info *cifs_sb);
#endif /* _CIFSPROTO_H */
diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index 5e24925..cababd8 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -512,13 +512,10 @@ int cifs_get_inode_info(struct inode **pinode,
cifs_sb->local_nls,
cifs_sb->mnt_cifs_flags &
CIFS_MOUNT_MAP_SPECIAL_CHR);
- if (rc1) {
+ if (rc1 || !fattr.cf_uniqueid) {
cFYI(1, ("GetSrvInodeNum rc %d", rc1));
fattr.cf_uniqueid = iunique(sb, ROOT_I);
- /* disable serverino if call not supported */
- if (rc1 == -EINVAL)
- cifs_sb->mnt_cifs_flags &=
- ~CIFS_MOUNT_SERVER_INUM;
+ cifs_autodisable_serverino(cifs_sb);
}
} else {
fattr.cf_uniqueid = iunique(sb, ROOT_I);
diff --git a/fs/cifs/misc.c b/fs/cifs/misc.c
index 0241b25..1e25efc 100644
--- a/fs/cifs/misc.c
+++ b/fs/cifs/misc.c
@@ -715,3 +715,17 @@ cifsConvertToUCS(__le16 *target, const char *source, int maxlen,
ctoUCS_out:
return i;
}
+
+void
+cifs_autodisable_serverino(struct cifs_sb_info *cifs_sb)
+{
+ if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SERVER_INUM) {
+ cifs_sb->mnt_cifs_flags &= CIFS_MOUNT_SERVER_INUM;
+ cERROR(1, ("Autodisabling the use of server inode numbers on "
+ "%s. This server doesn't seem to support them "
+ "properly. Hardlinks will not be recognized on this "
+ "mount. Consider mounting with the \"noserverino\" "
+ "option to silence this message.",
+ cifs_sb->tcon->treeName));
+ }
+}
diff --git a/fs/cifs/readdir.c b/fs/cifs/readdir.c
index 1f098ca..f84062f 100644
--- a/fs/cifs/readdir.c
+++ b/fs/cifs/readdir.c
@@ -727,11 +727,12 @@ static int cifs_filldir(char *pfindEntry, struct file *file, filldir_t filldir,
cifs_dir_info_to_fattr(&fattr, (FILE_DIRECTORY_INFO *)
pfindEntry, cifs_sb);

- /* FIXME: make _to_fattr functions fill this out */
- if (pCifsF->srch_inf.info_level == SMB_FIND_FILE_ID_FULL_DIR_INFO)
+ if (inum && (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SERVER_INUM)) {
fattr.cf_uniqueid = inum;
- else
+ } else {
fattr.cf_uniqueid = iunique(sb, ROOT_I);
+ cifs_autodisable_serverino(cifs_sb);
+ }

ino = cifs_uniqueid_to_ino_t(fattr.cf_uniqueid);
tmp_dentry = cifs_readdir_lookup(file->f_dentry, &qstring, &fattr);
--
1.6.0.6

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

suddenly doesn't work with the username and password in credentials=... in the mount line

2009-11-08T10:18:50Z

Hi,

I'm using Scientific Linux 5.3 (~ RedHat Enterprise 5.3).

After a reboot today, I probably have switched to a new kernel, "uname
-a" gives :

Linux yipkin.c-ad.bnl.gov 2.6.18-128.7.1.el5 #1 SMP Mon Aug 24 08:22:26
EDT 2009 i686 i686 i386 GNU/Linux

Somehow, the auto-mounting with cifs for the following line in
/etc/fstab doesn't work but it used to work :

//c-adweb/data /mnt/c-adweb cifs
domain=BNL,credentials=/root/.credentials,gid=kinyip,uid=kinyip 0 0

I see error in /var/log/message:
Nov 8 13:11:50 yipkin kernel: Status code returned 0xc000006d
NT_STATUS_LOGON_FAILURE
Nov 8 13:11:50 yipkin kernel: CIFS VFS: Send error in SessSetup = -13
Nov 8 13:11:50 yipkin kernel: CIFS VFS: cifs_mount failed w/return
code = -13

Using the command :
mount -t cifs -o
domain=BNL,credentials=/root/.credentials,gid=500,uid=500
//c-adweb/data /mnt/c-adweb

would get me :
mount error 13 = Permission denied
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

And I can see the same errors in /var/log/message (or dmesg).

If I do "mount -t cifs -o domain=BNL,user=kinyip,gid=500,uid=500
//c-adweb/data /mnt/c-adweb", it would ask me for password and
then it'd mount successfully !!

In my file /root/.credentials ("ls" would have : -rw------- 1 root root
39 Nov 8 13:02 /root/.credentials ), it's like
username=kinyip
password=$.....

My first character of my password is $ and I'm wondering whether this is
creating trouble ???? I've tried "\$...." but it doesn't help.

Any idea ???

Kin
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

Re: Can't mount smb shares using mount.cifs with 2.6.31 kernel

2009-11-01T17:40:59Z

On Fri, Oct 16, 2009 at 3:12 PM, Jeff Layton <jlayton@...> wrote:

>
> Yay. Figured out how to fix the wireshark dissector for this FindFile
> infolevel. Wireshark patch attached that allows me to dissect these
> packets correctly. I'll plan to send that to the wireshark devs as
> soon as I figure out where to send it. The good news is that I think I
> see the problem. The bad news is that I'm not quite sure how to fix it
> yet and it may even be a server bug.
>
> Prior to 2.6.30, the default was to generate inode numbers out of the
> air (noserverino). With 2.6.31, the default is "serverino" which makes
> it so that we query the server for inode numbers. When mounting, we do
> a QueryPathInfo against the root inode. With serverino enabled, we also
> do a FileInternalInfo query against the file for the
> "IndexNumber" (which I assumed was also the equivalent of the UniqueId
> but maybe isn't?). In any case, that first call succeeds against this
> server.
>
> The problem comes in with the FindFile call. There we do a
> FIND_FILE_ID_FULL_DIRECTORY_INFO infolevel query. That also succeeds,
> but the inode number values in there (FileId's) are zeroed out. That's
> technically within the letter of the spec for that call. When the
> underlying filesystem doesn't support unique ID's, then it's supposed
> to return 0. The problem is that it doesn't make much sense for the
> server to claim that it does support unique ID's for one call but not
> for others.
>
> Ideally, there'll be a way to deal with this automatically, but I'll
> probably need to ponder this a bit. In any case, thanks for the problem
> report. I'll let you know once I come up with something.
>

I'm very sorry I took so long to try out this patch. It appears to
have done the trick. Thanks!

--
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Open Graphics Project
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

Re: mount.cifs with sec=krb5 where kerberos principal is not the same as file server

2009-10-28T13:04:20Z

Hi Jeff,

On Wednesday 28 October 2009 14.08:30 Jeff Layton wrote:
> By "valid host" do you mean that it's a separate machine entirely? Or
> are you playing around with floating addresses in a clustered setup?

As it was explained to me, this is a cluster setup where the cluster nodes
have multiple floating IP addresses (for different samba server instances), but
join the domain using their canonical host name.

> Either way, this appears to be a server misconfiguration. A properly
> configured server should accept principals for all possible hostname
> aliases. The fact that it's expecting a service principal for a
> completely different host and not accepting a service principal for one
> of its names looks broken to me.

Ok... I've reported that to the people who run the servers, but the upshot of
it seems to be that Windows and smbclient work in this case but mount.cifs
won't.

On Wednesday 28 October 2009 19.28:36 Jeff Layton wrote:
> Actually...I'm not terribly opposed to adding a mount option for this.
> If someone wants to do the legwork on it and propose a patch, I'll be
> happy to help review it.

I don't have the cycles to do this myself -- I'm just going to make do with
password auth. However, thanks for your help and explanations.

Andrew
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

Re: mount.cifs with sec=krb5 where kerberos principal is not the same as file server

2009-10-28T11:28:36Z

On Wed, 28 Oct 2009 13:49:58 +0100
Andrew Baumann <andrewb@...> wrote:

> Hi Jeff,
>
> On Wednesday 28 October 2009 13.31:27 Jeff Layton wrote:
> > The reason is that while CIFS doesn't currently do mutual krb5
> > authentication, eventually it should. The problem with trusting the
> > mechListMIC is that it makes the client susceptible to
> > man-in-the-middle attacks. An attacker could redirect traffic to a
> > server of his choosing (perhaps by spoofing DNS) and the client would
> > be none the wiser.
>
> Hm, I see. Do you happen to know if smbclient does this? In the interim,
> perhaps it would be useful to have a mount option that could specify the
> service principal explicitly.
>

Actually...I'm not terribly opposed to adding a mount option for this.
If someone wants to do the legwork on it and propose a patch, I'll be
happy to help review it.

--
Jeff Layton <jlayton@...>
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

Re: mount.cifs with sec=krb5 where kerberos principal is not the same as file server

2009-10-28T06:08:30Z

On Wed, 28 Oct 2009 13:49:58 +0100
Andrew Baumann <andrewb@...> wrote:

I think that would be unwise -- why use kerberos at all if you're going
to water it down?

> > Now...when you say that fs-srv1 is a different host from the file
> > server, what exactly do you mean?
>
> I mean that it is a valid host with a different IP from the host with the
> share, and it does not itself offer SMB service:
>
> $ host fs.systems
> fs.systems.inf.ethz.ch is an alias for fs-systems.inf.ethz.ch.
> fs-systems.inf.ethz.ch has address 129.132.19.42
> $ host fs-srv1
> fs-srv1.ethz.ch is an alias for fs-srv1.inf.ethz.ch.
> fs-srv1.inf.ethz.ch has address 129.132.19.5
> $ telnet fs-srv1 microsoft-ds
> Trying 129.132.19.5...
> telnet: Unable to connect to remote host: Connection refused
>
> (I don't know the exact details of the file service setup here, but I can find
> out more if it's helpful).
>

By "valid host" do you mean that it's a separate machine entirely? Or
are you playing around with floating addresses in a clustered setup?

Either way, this appears to be a server misconfiguration. A properly
configured server should accept principals for all possible hostname
aliases. The fact that it's expecting a service principal for a
completely different host and not accepting a service principal for one
of its names looks broken to me.

--
Jeff Layton <jlayton@...>
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

Re: mount.cifs with sec=krb5 where kerberos principal is not the same as file server

2009-10-28T05:49:58Z

Hi Jeff,

On Wednesday 28 October 2009 13.31:27 Jeff Layton wrote:
> The reason is that while CIFS doesn't currently do mutual krb5
> authentication, eventually it should. The problem with trusting the
> mechListMIC is that it makes the client susceptible to
> man-in-the-middle attacks. An attacker could redirect traffic to a
> server of his choosing (perhaps by spoofing DNS) and the client would
> be none the wiser.

Hm, I see. Do you happen to know if smbclient does this? In the interim,
perhaps it would be useful to have a mount option that could specify the
service principal explicitly.

> Now...when you say that fs-srv1 is a different host from the file
> server, what exactly do you mean?

I mean that it is a valid host with a different IP from the host with the
share, and it does not itself offer SMB service:

$ host fs.systems
fs.systems.inf.ethz.ch is an alias for fs-systems.inf.ethz.ch.
fs-systems.inf.ethz.ch has address 129.132.19.42
$ host fs-srv1
fs-srv1.ethz.ch is an alias for fs-srv1.inf.ethz.ch.
fs-srv1.inf.ethz.ch has address 129.132.19.5
$ telnet fs-srv1 microsoft-ds
Trying 129.132.19.5...
telnet: Unable to connect to remote host: Connection refused

(I don't know the exact details of the file service setup here, but I can find
out more if it's helpful).

Andrew
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

Re: mount.cifs with sec=krb5 where kerberos principal is not the same as file server

2009-10-28T05:31:27Z

On Wed, 28 Oct 2009 10:20:26 +0100
Andrew Baumann <andrewb@...> wrote:

> Hi all,
>
> I'm trying to get mount.cifs to work with kerberos authentication (sec=krb5).
> smbclient -k works, however mount.cifs reports:
>
> $ /sbin/mount.cifs //fs.systems.inf.ethz.ch/sharename ./mnt -o sec=krb5
> mount error(126): Required key not available
> Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
>
> The dmesg output is as follows:
> [3460893.349868] /build/buildd/linux-2.6.28/fs/cifs/cifsfs.c: Devname: //fs.systems.inf.ethz.ch/sharename flags: 64
> [3460893.349874] /build/buildd/linux-2.6.28/fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 147 with uid: 0
> [3460893.349882] /build/buildd/linux-2.6.28/fs/cifs/connect.c: Username: username
> [3460893.349885] /build/buildd/linux-2.6.28/fs/cifs/connect.c: UNC: \\fs.systems.inf.ethz.ch\sharename ip: 129.132.19.42
> [3460893.349894] /build/buildd/linux-2.6.28/fs/cifs/connect.c: Socket created
> [3460893.350930] /build/buildd/linux-2.6.28/fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380 rcvtimeo 0x7fffffffffffffff
> [3460893.350973] /build/buildd/linux-2.6.28/fs/cifs/connect.c: Existing smb sess not found
> [3460893.350979] /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: secFlags 0x8
> [3460893.350981] /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: Kerberos only mechanism, enable extended security
> [3460893.350985] /build/buildd/linux-2.6.28/fs/cifs/transport.c: For smb_command 114
> [3460893.350988] /build/buildd/linux-2.6.28/fs/cifs/transport.c: Sending smb of length 78
> [3460893.351004] /build/buildd/linux-2.6.28/fs/cifs/connect.c: Demultiplex PID: 28499
> [3460893.354098] /build/buildd/linux-2.6.28/fs/cifs/connect.c: rfc1002 length 0xb7
> [3460893.355167] /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: Dialect: 2
> [3460893.355173] /build/buildd/linux-2.6.28/fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0x1bb92
> [3460893.355176] /build/buildd/linux-2.6.28/fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
> [3460893.355179] /build/buildd/linux-2.6.28/fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
> [3460893.355182] /build/buildd/linux-2.6.28/fs/cifs/asn1.c: Need to call asn1_octets_decode() function for cifs/fs-
> srv1.inf.ethz.ch@...
> [3460893.355185] /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: Signing disabled
> [3460893.355190] /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: negprot rc 0
> [3460893.355192] /build/buildd/linux-2.6.28/fs/cifs/connect.c: Security Mode: 0x3 Capabilities: 0x8000f3fd TimeAdjust: -3600
> [3460893.355196] /build/buildd/linux-2.6.28/fs/cifs/sess.c: sess setup type 6
> [3460893.355202] /build/buildd/linux-2.6.28/fs/cifs/cifs_spnego.c: key description =
> ver=0x2;host=fs.systems.inf.ethz.ch;ip4=129.132.19.42;sec=krb5;uid=0xc926;user=username
> [3460893.410781] /build/buildd/linux-2.6.28/fs/cifs/sess.c: ssetup freeing small buf ffff880114155dc0
> [3460893.410786] CIFS VFS: Send error in SessSetup = -126
> [3460893.410796] /build/buildd/linux-2.6.28/fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 147) rc = -126
> [3460893.410799] CIFS VFS: cifs_mount failed w/return code = -126
>
> ... from this, and looking at packet capture logs, it seems that the negotiate
> response from the server specifies a principal of cifs/fs-srv1.inf.ethz.ch@...
> however the cifs code persists in trying to get a kerberos ticket for the file
> server host (fs.systems.inf.ethz.ch), which fails. smbclient gets this right and
> presents the cached ticket for cifs/fs-srv1.inf.ethz.ch@....
>
> Note that is really a different host from the file server, so I cannot
> work around this problem by simply mounting with a different host name.
>
> Here is the full negotiate response from the server (and I can send other
> packet logs if useful):
>
> NetBIOS Session Service
> Message Type: Session message
> Length: 179
> SMB (Server Message Block Protocol)
> SMB Header
> Server Component: SMB
> [Response to: 4]
> [Time from request: 0.001272000 seconds]
> SMB Command: Negotiate Protocol (0x72)
> NT Status: STATUS_SUCCESS (0x00000000)
> Flags: 0x88
> 1... .... = Request/Response: Message is a response to the client/redirector
> .0.. .... = Notify: Notify client only on open
> ..0. .... = Oplocks: OpLock not requested/granted
> ...0 .... = Canonicalized Pathnames: Pathnames are not canonicalized
> .... 1... = Case Sensitivity: Path names are caseless
> .... ..0. = Receive Buffer Posted: Receive buffer has not been posted
> .... ...0 = Lock and Read: Lock&Read, Write&Unlock are not supported
> Flags2: 0xc801
> 1... .... .... .... = Unicode Strings: Strings are Unicode
> .1.. .... .... .... = Error Code Type: Error codes are NT error codes
> ..0. .... .... .... = Execute-only Reads: Don't permit reads if execute-only
> ...0 .... .... .... = Dfs: Don't resolve pathnames with Dfs
> .... 1... .... .... = Extended Security Negotiation: Extended security negotiation is supported
> .... .... .0.. .... = Long Names Used: Path names in request are not long file names
> .... .... .... .0.. = Security Signatures: Security signatures are not supported
> .... .... .... ..0. = Extended Attributes: Extended attributes are not supported
> .... .... .... ...1 = Long Names Allowed: Long file names are allowed in the response
> Process ID High: 0
> Signature: 0000000000000000
> Reserved: 0000
> Tree ID: 0
> Process ID: 28048
> User ID: 0
> Multiplex ID: 1
> Negotiate Protocol Response (0x72)
> Word Count (WCT): 17
> Dialect Index: 8, greater than LANMAN2.1
> Security Mode: 0x03
> .... ...1 = Mode: USER security mode
> .... ..1. = Password: ENCRYPTED password. Use challenge/response
> .... .0.. = Signatures: Security signatures NOT enabled
> .... 0... = Sig Req: Security signatures NOT required
> Max Mpx Count: 50
> Max VCs: 1
> Max Buffer Size: 16644
> Max Raw Buffer: 65536
> Session Key: 0x00001ed9
> Capabilities: 0x8000f3fd
> .... .... .... .... .... .... .... ...1 = Raw Mode: Read Raw and Write Raw are supported
> .... .... .... .... .... .... .... ..0. = MPX Mode: Read Mpx and Write Mpx are not supported
> .... .... .... .... .... .... .... .1.. = Unicode: Unicode strings are supported
> .... .... .... .... .... .... .... 1... = Large Files: Large files are supported
> .... .... .... .... .... .... ...1 .... = NT SMBs: NT SMBs are supported
> .... .... .... .... .... .... ..1. .... = RPC Remote APIs: RPC remote APIs are supported
> .... .... .... .... .... .... .1.. .... = NT Status Codes: NT status codes are supported
> .... .... .... .... .... .... 1... .... = Level 2 Oplocks: Level 2 oplocks are supported
> .... .... .... .... .... ...1 .... .... = Lock and Read: Lock and Read is supported
> .... .... .... .... .... ..1. .... .... = NT Find: NT Find is supported
> .... .... .... .... ...1 .... .... .... = Dfs: Dfs is supported
> .... .... .... .... ..1. .... .... .... = Infolevel Passthru: NT information level request passthrough is supported
> .... .... .... .... .1.. .... .... .... = Large ReadX: Large Read andX is supported
> .... .... .... .... 1... .... .... .... = Large WriteX: Large Write andX is supported
> .... .... 0... .... .... .... .... .... = UNIX: UNIX extensions are not supported
> .... ..0. .... .... .... .... .... .... = Reserved: Reserved
> ..0. .... .... .... .... .... .... .... = Bulk Transfer: Bulk Read and Bulk Write are not supported
> .0.. .... .... .... .... .... .... .... = Compressed Data: Compressed data transfer is not supported
> 1... .... .... .... .... .... .... .... = Extended Security: Extended security exchanges are supported
> System Time: Oct 28, 2009 09:42:32.000000000
> Server Time Zone: -60 min from UTC
> Key Length: 0
> Byte Count (BCC): 110
> Server GUID: 66732D73727631000000000000000000
> Security Blob: 605C06062B0601050502A0523050A024302206092A864886...
> GSS-API Generic Security Service Application Program Interface
> OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
> SPNEGO
> negTokenInit
> mechTypes: 3 items
> Item: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
> Item: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5)
> Item: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP - Microsoft NTLM Security Support Provider)
> mechListMIC: 3026A0241B22636966732F66732D737276312E696E662E65...
> principal: cifs/fs-srv1.inf.ethz.ch@...
>
>

CIFS currently relies on you to specify the same hostname in the UNC as
the krb5 service principal that you need to mount.

The reason is that while CIFS doesn't currently do mutual krb5
authentication, eventually it should. The problem with trusting the
mechListMIC is that it makes the client susceptible to
man-in-the-middle attacks. An attacker could redirect traffic to a
server of his choosing (perhaps by spoofing DNS) and the client would
be none the wiser.

Now...when you say that fs-srv1 is a different host from the file
server, what exactly do you mean?

--
Jeff Layton <jlayton@...>
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

mount.cifs with sec=krb5 where kerberos principal is not the same as file server

2009-10-28T02:20:26Z

Hi all,

I'm trying to get mount.cifs to work with kerberos authentication (sec=krb5).
smbclient -k works, however mount.cifs reports:

$ /sbin/mount.cifs //fs.systems.inf.ethz.ch/sharename ./mnt -o sec=krb5
mount error(126): Required key not available
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

The dmesg output is as follows:
[3460893.349868] /build/buildd/linux-2.6.28/fs/cifs/cifsfs.c: Devname: //fs.systems.inf.ethz.ch/sharename flags: 64
[3460893.349874] /build/buildd/linux-2.6.28/fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 147 with uid: 0
[3460893.349882] /build/buildd/linux-2.6.28/fs/cifs/connect.c: Username: username
[3460893.349885] /build/buildd/linux-2.6.28/fs/cifs/connect.c: UNC: \\fs.systems.inf.ethz.ch\sharename ip: 129.132.19.42
[3460893.349894] /build/buildd/linux-2.6.28/fs/cifs/connect.c: Socket created
[3460893.350930] /build/buildd/linux-2.6.28/fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380 rcvtimeo 0x7fffffffffffffff
[3460893.350973] /build/buildd/linux-2.6.28/fs/cifs/connect.c: Existing smb sess not found
[3460893.350979] /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: secFlags 0x8
[3460893.350981] /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: Kerberos only mechanism, enable extended security
[3460893.350985] /build/buildd/linux-2.6.28/fs/cifs/transport.c: For smb_command 114
[3460893.350988] /build/buildd/linux-2.6.28/fs/cifs/transport.c: Sending smb of length 78
[3460893.351004] /build/buildd/linux-2.6.28/fs/cifs/connect.c: Demultiplex PID: 28499
[3460893.354098] /build/buildd/linux-2.6.28/fs/cifs/connect.c: rfc1002 length 0xb7
[3460893.355167] /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: Dialect: 2
[3460893.355173] /build/buildd/linux-2.6.28/fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0x1bb92
[3460893.355176] /build/buildd/linux-2.6.28/fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
[3460893.355179] /build/buildd/linux-2.6.28/fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
[3460893.355182] /build/buildd/linux-2.6.28/fs/cifs/asn1.c: Need to call asn1_octets_decode() function for cifs/fs-
srv1.inf.ethz.ch@...
[3460893.355185] /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: Signing disabled
[3460893.355190] /build/buildd/linux-2.6.28/fs/cifs/cifssmb.c: negprot rc 0
[3460893.355192] /build/buildd/linux-2.6.28/fs/cifs/connect.c: Security Mode: 0x3 Capabilities: 0x8000f3fd TimeAdjust: -3600
[3460893.355196] /build/buildd/linux-2.6.28/fs/cifs/sess.c: sess setup type 6
[3460893.355202] /build/buildd/linux-2.6.28/fs/cifs/cifs_spnego.c: key description =
ver=0x2;host=fs.systems.inf.ethz.ch;ip4=129.132.19.42;sec=krb5;uid=0xc926;user=username
[3460893.410781] /build/buildd/linux-2.6.28/fs/cifs/sess.c: ssetup freeing small buf ffff880114155dc0
[3460893.410786] CIFS VFS: Send error in SessSetup = -126
[3460893.410796] /build/buildd/linux-2.6.28/fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 147) rc = -126
[3460893.410799] CIFS VFS: cifs_mount failed w/return code = -126

... from this, and looking at packet capture logs, it seems that the negotiate
response from the server specifies a principal of cifs/fs-srv1.inf.ethz.ch@...
however the cifs code persists in trying to get a kerberos ticket for the file
server host (fs.systems.inf.ethz.ch), which fails. smbclient gets this right and
presents the cached ticket for cifs/fs-srv1.inf.ethz.ch@....

Note that fs-srv1 is really a different host from the file server, so I cannot
work around this problem by simply mounting with a different host name.

Here is the full negotiate response from the server (and I can send other
packet logs if useful):

NetBIOS Session Service
Message Type: Session message
Length: 179
SMB (Server Message Block Protocol)
SMB Header
Server Component: SMB
[Response to: 4]
[Time from request: 0.001272000 seconds]
SMB Command: Negotiate Protocol (0x72)
NT Status: STATUS_SUCCESS (0x00000000)
Flags: 0x88
1... .... = Request/Response: Message is a response to the client/redirector
.0.. .... = Notify: Notify client only on open
..0. .... = Oplocks: OpLock not requested/granted
...0 .... = Canonicalized Pathnames: Pathnames are not canonicalized
.... 1... = Case Sensitivity: Path names are caseless
.... ..0. = Receive Buffer Posted: Receive buffer has not been posted
.... ...0 = Lock and Read: Lock&Read, Write&Unlock are not supported
Flags2: 0xc801
1... .... .... .... = Unicode Strings: Strings are Unicode
.1.. .... .... .... = Error Code Type: Error codes are NT error codes
..0. .... .... .... = Execute-only Reads: Don't permit reads if execute-only
...0 .... .... .... = Dfs: Don't resolve pathnames with Dfs
.... 1... .... .... = Extended Security Negotiation: Extended security negotiation is supported
.... .... .0.. .... = Long Names Used: Path names in request are not long file names
.... .... .... .0.. = Security Signatures: Security signatures are not supported
.... .... .... ..0. = Extended Attributes: Extended attributes are not supported
.... .... .... ...1 = Long Names Allowed: Long file names are allowed in the response
Process ID High: 0
Signature: 0000000000000000
Reserved: 0000
Tree ID: 0
Process ID: 28048
User ID: 0
Multiplex ID: 1
Negotiate Protocol Response (0x72)
Word Count (WCT): 17
Dialect Index: 8, greater than LANMAN2.1
Security Mode: 0x03
.... ...1 = Mode: USER security mode
.... ..1. = Password: ENCRYPTED password. Use challenge/response
.... .0.. = Signatures: Security signatures NOT enabled
.... 0... = Sig Req: Security signatures NOT required
Max Mpx Count: 50
Max VCs: 1
Max Buffer Size: 16644
Max Raw Buffer: 65536
Session Key: 0x00001ed9
Capabilities: 0x8000f3fd
.... .... .... .... .... .... .... ...1 = Raw Mode: Read Raw and Write Raw are supported
.... .... .... .... .... .... .... ..0. = MPX Mode: Read Mpx and Write Mpx are not supported
.... .... .... .... .... .... .... .1.. = Unicode: Unicode strings are supported
.... .... .... .... .... .... .... 1... = Large Files: Large files are supported
.... .... .... .... .... .... ...1 .... = NT SMBs: NT SMBs are supported
.... .... .... .... .... .... ..1. .... = RPC Remote APIs: RPC remote APIs are supported
.... .... .... .... .... .... .1.. .... = NT Status Codes: NT status codes are supported
.... .... .... .... .... .... 1... .... = Level 2 Oplocks: Level 2 oplocks are supported
.... .... .... .... .... ...1 .... .... = Lock and Read: Lock and Read is supported
.... .... .... .... .... ..1. .... .... = NT Find: NT Find is supported
.... .... .... .... ...1 .... .... .... = Dfs: Dfs is supported
.... .... .... .... ..1. .... .... .... = Infolevel Passthru: NT information level request passthrough is supported
.... .... .... .... .1.. .... .... .... = Large ReadX: Large Read andX is supported
.... .... .... .... 1... .... .... .... = Large WriteX: Large Write andX is supported
.... .... 0... .... .... .... .... .... = UNIX: UNIX extensions are not supported
.... ..0. .... .... .... .... .... .... = Reserved: Reserved
..0. .... .... .... .... .... .... .... = Bulk Transfer: Bulk Read and Bulk Write are not supported
.0.. .... .... .... .... .... .... .... = Compressed Data: Compressed data transfer is not supported
1... .... .... .... .... .... .... .... = Extended Security: Extended security exchanges are supported
System Time: Oct 28, 2009 09:42:32.000000000
Server Time Zone: -60 min from UTC
Key Length: 0
Byte Count (BCC): 110
Server GUID: 66732D73727631000000000000000000
Security Blob: 605C06062B0601050502A0523050A024302206092A864886...
GSS-API Generic Security Service Application Program Interface
OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
SPNEGO
negTokenInit
mechTypes: 3 items
Item: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
Item: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5)
Item: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP - Microsoft NTLM Security Support Provider)
mechListMIC: 3026A0241B22636966732F66732D737276312E696E662E65...
principal: cifs/fs-srv1.inf.ethz.ch@...

$ uname -a
Linux prak 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 19:25:34 UTC 2009 x86_64 GNU/Linux
$ /sbin/mount.cifs -V
mount.cifs version: 1.12-3.3.2
$ smbclient -V
Version 3.3.2
$ /usr/sbin/cifs.upcall -v
version: 1.2
$ grep cifs /etc/request-key.conf
create cifs.spnego * * /usr/sbin/cifs.upcall -c %k %d
create dns_resolver * * /usr/sbin/cifs.upcall -c %k

Cheers,
Andrew

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[PATCH] cifs: don't use CIFSGetSrvInodeNumber in is_path_accessible

2009-10-27T08:02:44Z

Because it's lighter weight, CIFS tries to do a QPathInfo call with an
infolevel of SMB_QUERY_FILE_INTERNAL_INFO to verify the accessibility of
the root inode. It then falls back to using an infolevel of
SMB_QUERY_FILE_ALL_INFO if that fails with -EOPNOTSUPP.

There's a problem however. SMB_QUERY_FILE_INTERNAL_INFO isn't as well
supported by all servers as SMB_QUERY_FILE_ALL_INFO is, and the error
returns from those servers aren't well standardized. I have at least one
report of a server that returns NT_STATUS_INTERNAL_ERROR (which
translates to EIO) rather than something that translates to EOPNOTSUPP.

Given that that function only gets called at mount time, I think it's
better to do this as simply as possible. Rather than trying to be
clever, just have is_path_accessible use SMB_QUERY_FILE_ALL_INFO. That
call is widely supported and it shouldn't increase the overhead
significantly.

Unfortunately, the reporter of this problem doesn't seem to be in a
hurry to test it, so I don't have any test results from it. Given what I
see in the captures though, I expect that this will fix the problem.

Signed-off-by: Jeff Layton <jlayton@...>
---
fs/cifs/connect.c | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index b090980..63ea83f 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -2220,16 +2220,8 @@ is_path_accessible(int xid, struct cifsTconInfo *tcon,
struct cifs_sb_info *cifs_sb, const char *full_path)
{
int rc;
- __u64 inode_num;
FILE_ALL_INFO *pfile_info;

- rc = CIFSGetSrvInodeNumber(xid, tcon, full_path, &inode_num,
- cifs_sb->local_nls,
- cifs_sb->mnt_cifs_flags &
- CIFS_MOUNT_MAP_SPECIAL_CHR);
- if (rc != -EOPNOTSUPP)
- return rc;
-
pfile_info = kmalloc(sizeof(FILE_ALL_INFO), GFP_KERNEL);
if (pfile_info == NULL)
return -ENOMEM;
--
1.6.0.6

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[PATCH] cifs: fix server returning zeroed out FileID's in SMB_FIND_FILE_ID_FULL_DIR_INFO

2009-10-27T08:02:43Z

Re: Manual page for mount.cifs credentials option

2009-10-27T05:34:12Z

On Tue, 27 Oct 2009 07:29:47 -0400
Scott Lovenberg <scott.lovenberg@...> wrote:

> Jeff Layton wrote:On Thu, 22 Oct 2009 12:49:05 -0400
> Scott Lovenberg <scott.lovenberg@...> wrote:
>
> Not sure if this is the correct place to file this report, if not, please point me in the correct direction.
>
> The credentials option for mount.smbfs used to be the following format:
> user=name
> password=pass
>
> I've found that the format supported for mount.cifs is:
> username=name
> password=pass
>
> This seems at odds with the manual page for mount.cifs under the user=arg option:
> [...]
> Note
> The cifs vfs accepts the parameter user=, or for users familiar with smbfs it
> accepts the longer form of the parameter username=. Similarly the longer smbfs
> style parameter names may be accepted as synonyms for the shorter cifs
> parameters pass=,dom= and cred=.
> [...]
>
> I had, for whatever reason, assumed that the user option rules would apply to the credentials file or that it would be backwards compatible with the older mount.smbfs credentials file format. Are either of these assumptions correct? If not, would it make sense to add or reword the manual page a bit (assuming I'm not the only one that misinterpreted it) for clarity? I wouldn't mind drafting up a proposal if other felt it was worth the effort.
>
>
> Happy Version Numbers:
> from The Fine Manual page for mount.cifs(8)
> VERSION
> This man page is correct for version 1.52 of the cifs vfs filesystem (roughly Linux kernel 2.6.24).
> [1005 12:24 sun ~]#smbd -V
> Version 3.0.33-3.7.el5
> [1007 12:26 sun ~]#uname -a
> Linux sanitized.network.tld 2.6.18-92.1.22.el5.centos.plusxen #1 SMP Wed Dec 17 11:22:13 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
>
> Consistency here would probably be a good thing. A proposal for
> cleaning it up would be welcome. Patches would be even better.
>
> The weekend slipped away from me (they all seem to do that lately...); I'm going to take a look at this tonight after work.
>
> Would you agree that it is more desirable to add the "user=" format to mount.cifs to maintain backwards compatibility? I think this is probably the most 'clean' way to deal with it.

I agree that it would be good to have cifs be option-compatible with
smbfs. Not sure when we'll get to this however. It would probably be
best to file a bug at:

http://bugzilla.samba.org/

So we don't lose track of it.

Thanks,
--
Jeff Layton <jlayton@...>
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

Re: Manual page for mount.cifs credentials option

2009-10-27T04:29:47Z

Jeff Layton wrote:

On Thu, 22 Oct 2009 12:49:05 -0400
Scott Lovenberg scott.lovenberg@... wrote:

Not sure if this is the correct place to file this report, if not, please point me in the correct direction.

The credentials option for mount.smbfs used to be the following format:
    user=name
    password=pass

I've found that the format supported for mount.cifs is:
    username=name
    password=pass

This seems at odds with the manual page for mount.cifs under the user=arg option:
    [...]
           Note
           The cifs vfs accepts the parameter user=, or for users familiar with smbfs it
           accepts the longer form of the parameter username=. Similarly the longer smbfs
           style parameter names may be accepted as synonyms for the shorter cifs
           parameters pass=,dom= and cred=.
    [...]

I had, for whatever reason, assumed that the user option rules would apply to the credentials file or that it would be backwards compatible with the older mount.smbfs credentials file format.  Are either of these assumptions correct?  If not, would it make sense to add or reword the manual page a bit (assuming I'm not the only one that misinterpreted it) for clarity?  I wouldn't mind drafting up a proposal if other felt it was worth the effort.


Happy Version Numbers:
from The Fine Manual page for mount.cifs(8)
        VERSION
           This man page is correct for version 1.52 of the cifs vfs filesystem (roughly Linux kernel 2.6.24).
[1005 12:24 sun ~]#smbd -V
Version 3.0.33-3.7.el5
[1007 12:26 sun ~]#uname -a
Linux sanitized.network.tld 2.6.18-92.1.22.el5.centos.plusxen #1 SMP Wed Dec 17 11:22:13 EST 2008 x86_64 x86_64 x86_64 GNU/Linux


Consistency here would probably be a good thing. A proposal for
cleaning it up would be welcome. Patches would be even better.

The weekend slipped away from me (they all seem to do that lately...); I'm going to take a look at this tonight after work.

Would you agree that it is more desirable to add the "user=" format to mount.cifs to maintain backwards compatibility? I think this is probably the most 'clean' way to deal with it.

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

Re: Hello

2009-10-27T03:45:22Z

On Mon, 26 Oct 2009 14:06:13 -0400
Linux User <linuxuser09@...> wrote:

> I'm not sure if I am on the right mailing list for this questions. I'm having
> a hard time understanding/setting file permissions/uid/gid on the client side.
>
> Here's my mount line:
>
> sudo mount.cifs //comp2.localnet.webwaredev.org/games /mnt/games-share -v -o
> uid=500 gid=networkshares file_mode=0775 dir_mode=0775
>
> It's in verbose and this was what was outputted:
>
> mount.cifs kernel mount options:
> unc=//comp2.localnet.webwaredev.org\games,user=root,ver=1,uid=500,ip=192.168.0.3,pass=********
>
> And this is what I am running into:
>
> [lhorace@netsrv games-share]$ cd test
> [lhorace@netsrv test]$ mkdir test2
> [lhorace@netsrv test]$ ls -l
> total 0
> drwxr-xr-x. 2 lhorace root 0 2009-10-26 12:28 test2
> [lhorace@netsrv test]$ touch filetext.txt
> touch: cannot touch `filetext.txt': Permission denied
> [lhorace@netsrv test]$ cd test2
> [lhorace@netsrv test2]$ touch filetest.txt
> touch: cannot touch `filetest.txt': Permission denied
> [lhorace@netsrv test2]$
>
> On a regular filesystem folder, if I am the owner of the folder, I should be
> able to create files within the folder. And reading the output correctly, it
> seems that uid is the only thing that get's pass to the kernel.
>
> Note: uid=500 = lhorace, and lhorace exists on bothsystems including
> networkshares.
>
> What am I doing wrong? Any hints/clues would be entirely appreciative thank
> you.. =)

Permissions on CIFS are confusing stuff...

CIFS doesn't manage multiple credentials per mount. In this case,
you're mounting the share with "user=root". So even though on the local
machine you're "lhorace" and the dir is owned by "lhorace" on the
server, the call goes out over the wire as "root" (which is probably
being mapped to an unprivileged user).

You probably want to redo the mount with user=lhorace, but be
forewarned that all the activity will be done as "lhorace" no matter
what user on the client is doing this activity.

--
Jeff Layton <jlayton@...>
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

Hello

2009-10-26T11:06:13Z

I'm not sure if I am on the right mailing list for this questions. I'm having
a hard time understanding/setting file permissions/uid/gid on the client side.

Here's my mount line:

sudo mount.cifs //comp2.localnet.webwaredev.org/games /mnt/games-share -v -o
uid=500 gid=networkshares file_mode=0775 dir_mode=0775

It's in verbose and this was what was outputted:

mount.cifs kernel mount options:
unc=//comp2.localnet.webwaredev.org\games,user=root,ver=1,uid=500,ip=192.168.0.3,pass=********

And this is what I am running into:

[lhorace@netsrv games-share]$ cd test
[lhorace@netsrv test]$ mkdir test2
[lhorace@netsrv test]$ ls -l
total 0
drwxr-xr-x. 2 lhorace root 0 2009-10-26 12:28 test2
[lhorace@netsrv test]$ touch filetext.txt
touch: cannot touch `filetext.txt': Permission denied
[lhorace@netsrv test]$ cd test2
[lhorace@netsrv test2]$ touch filetest.txt
touch: cannot touch `filetest.txt': Permission denied
[lhorace@netsrv test2]$

On a regular filesystem folder, if I am the owner of the folder, I should be
able to create files within the folder. And reading the output correctly, it
seems that uid is the only thing that get's pass to the kernel.

Note: uid=500 = lhorace, and lhorace exists on bothsystems including
networkshares.

What am I doing wrong? Any hints/clues would be entirely appreciative thank
you.. =)
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

Re: Question on current stateofsec=krb5*integration in cifs.ko

2009-10-26T06:14:08Z

Hi Volker,

ok, did the same grep as below, but this time for "crypt". I now came
accross a parameter named

smb encrypt

Is that the right one (from the smb.conf man page it seems to be)?
Furthermore, "smb encrypt" seems to include *both* signing and
encryption, so one "smb encrypt" is set to mandatory, "server signing
= mandatory" should no longer be required, right?

Besides, why not rename "server signing" to "smb signing" for
consistency (would also make it easier to grep for it)?

Greetings,

Holger

Volker Lendecke schrieb am Monday, den 26. October 2009:

> On Mon, Oct 26, 2009 at 10:56:42AM +0100, Holger Rauch wrote:
> > [...]
> > Does "server signing = mandatory" also include encryption? I did a
> > "testparm - v | grep server" and additional option containing
> > "encryption" was shown, so I guess "server signing" includes both
> > signing *and* encryption, right?
>
> No.
>
> Volker

=========================================
Holger Rauch
Entwicklung Anwendungs-Software
Systemadministration UNIX

Tel.: +49 / 9131 / 877 - 141
Fax: +49 / 9131 / 877 - 266
Email: Holger.Rauch@...
=========================================

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

signature.asc (204 bytes) Download Attachment

Re: Question on current state ofsec=krb5*integration in cifs.ko

2009-10-26T04:23:50Z

On Mon, Oct 26, 2009 at 10:56:42AM +0100, Holger Rauch wrote:

> Hi Volker,
>
> Volker Lendecke schrieb am Friday, den 23. October 2009:
>
> > [...]
> > For the server you would say "server signing = mandatory",
> > no idea about mount.cifs.
>
> For mount.cifs, specifying sec=krb5i instead of sec=krb5 in my
> automount map obviously worked. The file system was automounted as
> expected.
>
> Does "server signing = mandatory" also include encryption? I did a
> "testparm - v | grep server" and additional option containing
> "encryption" was shown, so I guess "server signing" includes both
> signing *and* encryption, right?

No.

Volker
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

Re: Question on current state ofsec=krb5*integration in cifs.ko

2009-10-26T02:56:42Z

Hi Volker,

Volker Lendecke schrieb am Friday, den 23. October 2009:

> [...]
> For the server you would say "server signing = mandatory",
> no idea about mount.cifs.

For mount.cifs, specifying sec=krb5i instead of sec=krb5 in my
automount map obviously worked. The file system was automounted as
expected.

Does "server signing = mandatory" also include encryption? I did a
"testparm - v | grep server" and additional option containing
"encryption" was shown, so I guess "server signing" includes both
signing *and* encryption, right?

Thanks for clarifying this & kind regards,

Holger

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

signature.asc (204 bytes) Download Attachment

Re: Question on current state of sec=krb5*integration in cifs.ko

2009-10-23T10:13:38Z

On Fri, Oct 23, 2009 at 06:20:40PM +0200, Holger Rauch wrote:
> Hi Volker,
>
> I looked at
>
> http://wiki.samba.org/index.php/UNIX_Extensions
>
> but I couldn't find anything about SMB encryption. Do you have any
> good links concerning both SMB signing and encryption (configuring it,
> smb.conf options, etc.)?

For the server you would say "server signing = mandatory",
no idea about mount.cifs.

> Are they both part of Samba 3.2.5 (shipped with Debian Lenny) or would
> I need a more recent version of Samba?

Samba 3.2.5 server-side does both signing and encryption.
cifs.ko afaik only does signing, no encryption yet (this was
the "Hint" part of my last mail :-))

Volker

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

signature.asc (204 bytes) Download Attachment

Re: Question on current state of sec=krb5* integration in cifs.ko

2009-10-23T10:13:19Z

On Fri, 23 Oct 2009 18:30:25 +0200
Holger Rauch <holger.rauch@...> wrote:

> Hi Jeff,
>
>
> On Fri, 23 Oct 2009, Jeff Layton wrote:
>
> > [...]
> > Yes, much...
> >
> > NFS (well, RPC actually) sends credentials with every call, so if you
> > destroy the creds, then the client and server will tend to pick up on
> > that fact rather quickly. With CIFS the credentials are just used to
> > establish a "session". After that, krb5 doesn't really come into play
> > very much (at least until you have to reconnect).
>
> Well, that surely explains the "kdestroy" thing, but the other
> interesting question is what software is actually meant by "server"
> in case the log message reads similar to "server doesn't support signing"?
>
> Any details for me on this one?
>

Sorry, it's a little difficult to be more specific...

It depends on what you're kind of server you're mounting here. If it's
windows, then you'll probably need to play with its settings. If you're
mounting samba, you probably need to set samba options to enable
signing. If something else...who knows?

--
Jeff Layton <jlayton@...>

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

signature.asc (205 bytes) Download Attachment

Re: Question on current state of sec=krb5* integration in cifs.ko

2009-10-23T09:41:04Z

On Fri, Oct 23, 2009 at 8:24 PM, Jeff Layton <jlayton@...> wrote:

> On Fri, 23 Oct 2009 20:00:59 +0400
> "Q (Igor Mammedov)" <qwerty0987654321@...> wrote:
>
>> On Fri, Oct 23, 2009 at 6:19 PM, Jeff Layton <jlayton@...> wrote:
>> > On Fri, 23 Oct 2009 15:54:29 +0200
>> > Holger Rauch <holger.rauch@...> wrote:
>> >
>> >> Hi Jeff,
>> >>
>> >> first of all, thanks for your quick reply.
>> >>
>> >> On Fri, 23 Oct 2009, Jeff Layton wrote:
>> >>
>> >> > On Fri, 23 Oct 2009 13:12:14 +0200
>> >> > Holger Rauch <holger.rauch@...> wrote:
>> >> > > [...]
>> >> > > I just tried that. Mount options in /etc/fstab are
>> >> > >
>> >> > > noauto,sec=krb5i,iocharset=iso8859-15
>> >> > >
>> >> > > When I issue the mount cmd, it asks me for a password.
>> >> >
>> >> > That probably means that you have a fairly old mount.cifs program. The
>> >> > more recent ones don't prompt for a password when sec=krb5* is
>> >> > specified. Try adding the "guest" option which will disable password
>> >> > prompting.
>> >>
>> >> Ok, I tried that (debugging output included as well; interestingly
>> >> enough, "mount.cifs -V" only outputs the help message, even if
>> >> mount.cifs is called with an absolute path). This happenend on a
>> >> Debian Lenny system having the shipped kernel version (uname -r):
>> >>
>> >> 2.6.26-2-686-bigmem
>> >>
>> >> Since "mount.cifs -V" didn't come up with version info, I used
>> >> "apt-cache show smbfs" ("smbfs" is the Debian package mount.cifs is
>> >> contained in). It has the same version as the other Samba packages
>> >> shipped with Debian: 3.2.5
>> >>
>> >> ==============
>> >>
>> >> pia:~# mount -t cifs //server/myuser
>> >> /cifs/user --verbose -o
>> >> sec=krb5i,user=myuser,guest,iocharset=iso8859-15
>> >> parsing options: rw,sec=krb5i,user=myuser,guest,iocharset=iso8859-15
>> >>
>> >> mount.cifs kernel mount options
>> >> unc=//server\myuser,ip=ww.xx.yy.zz,ver=1,rw,sec=krb5i,user=myuser,guest,iocharset=iso8859-15
>> >>
>> >> mount error 95 = Operation not supported
>> >> Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
>> >> pia:~# dmesg
>> >> [8046556.840192] fs/cifs/cifsfs.c: Devname:
>> >> //prag-old.er.heitec.net/hrauch flags: 64
>> >> [8046556.847954] fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid:
>> >> 15 with uid: 0
>> >> [8046556.895920] fs/cifs/connect.c: iocharset set to iso8859-15
>> >> [8046556.903932] fs/cifs/connect.c: Username: myuser
>> >> [8046556.911928] fs/cifs/connect.c: UNC:
>> >> \\server\myuser ip: ww.xx.yy.zz
>> >> [8046556.916743] fs/cifs/connect.c: Socket created
>> >> [8046556.924050] fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380
>> >> rcvtimeo 0x7fffffff
>> >> [8046556.935312] fs/cifs/connect.c: Existing smb sess not found
>> >> [8046556.935312] fs/cifs/connect.c: Demultiplex PID: 6171
>> >> [8046556.946262] fs/cifs/cifssmb.c: secFlags 0x1009
>> >> [8046556.950328] fs/cifs/cifssmb.c: Kerberos only mechanism, enable
>> >> extended security
>> >> [8046556.957962] fs/cifs/transport.c: For smb_command 114
>> >> [8046556.962692] fs/cifs/transport.c: Sending smb of length 78
>> >> [8046556.968883] fs/cifs/connect.c: rfc1002 length 0xbe
>> >> [8046556.974665] fs/cifs/cifssmb.c: Dialect: 2
>> >> [8046556.978940] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348
>> >> 0x1bb92
>> >> [8046556.989230] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
>> >> [8046556.991772] fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
>> >> [8046556.998296] fs/cifs/asn1.c: Need to call asn1_octets_decode()
>> >> function for cifs/server@MYREALM
>> >> [8046557.008389] fs/cifs/cifssmb.c: Must sign - secFlags 0x1009
>> >> [8046557.015170] CIFS VFS: signing required but server lacks support
>> >
>> >
>> > I think this message explains the problem ^^^^
>> >
>> > You've request krb5i, but your server doesn't support signing. You
>> > might want to try sec=krb5 and see if that works.
>>
>> That there won't be much security left with sec=krb, because of
>> it would lack even signed cisf packets. And as far as I remember,
>> the client doesn't do mutual authentication of the server, so
>> the server may be faked by any machine registered in the ADS
>> domain.
>> Any ways, we can use current cifs only to authenticate client
>> on the server only, but there won't be much security in the sense
>> of transmitted data or checking if we speak with real server.
>>
>
> My intention was not to claim that using krb5 instead of krb5i was a
> good idea...simply that he might want to try it to make sure that was
> the only problem.
>
> Obviously, fixing the server to support signing would be a better
> long term solution.

I'm Sorry if I was rude. Your solution to the problem is perfectly Ok.
I just complemented your answer with what security risks there are.

And implementing mutual authentication wasn't a simple thing when
I've looked at it. It will require to expand upcall protocol to do several
round-trips of SecurityBlob between KDC and cifs server.

>
> --
> Jeff Layton <jlayton@...>
>
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

Re: Question on current state of sec=krb5* integration in cifs.ko

2009-10-23T09:30:25Z

Hi Jeff,

On Fri, 23 Oct 2009, Jeff Layton wrote:

> [...]
> Yes, much...
>
> NFS (well, RPC actually) sends credentials with every call, so if you
> destroy the creds, then the client and server will tend to pick up on
> that fact rather quickly. With CIFS the credentials are just used to
> establish a "session". After that, krb5 doesn't really come into play
> very much (at least until you have to reconnect).

Well, that surely explains the "kdestroy" thing, but the other
interesting question is what software is actually meant by "server"
in case the log message reads similar to "server doesn't support signing"?

Any details for me on this one?

Thanks & kind regards,

Holger

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

signature.asc (204 bytes) Download Attachment

Re: Question on current state of sec=krb5* integration in cifs.ko

2009-10-23T09:24:19Z

On Fri, 23 Oct 2009 20:00:59 +0400
"Q (Igor Mammedov)" <qwerty0987654321@...> wrote:

> On Fri, Oct 23, 2009 at 6:19 PM, Jeff Layton <jlayton@...> wrote:
> > On Fri, 23 Oct 2009 15:54:29 +0200
> > Holger Rauch <holger.rauch@...> wrote:
> >
> >> Hi Jeff,
> >>
> >> first of all, thanks for your quick reply.
> >>
> >> On Fri, 23 Oct 2009, Jeff Layton wrote:
> >>
> >> > On Fri, 23 Oct 2009 13:12:14 +0200
> >> > Holger Rauch <holger.rauch@...> wrote:
> >> > > [...]
> >> > > I just tried that. Mount options in /etc/fstab are
> >> > >
> >> > > noauto,sec=krb5i,iocharset=iso8859-15
> >> > >
> >> > > When I issue the mount cmd, it asks me for a password.
> >> >
> >> > That probably means that you have a fairly old mount.cifs program. The
> >> > more recent ones don't prompt for a password when sec=krb5* is
> >> > specified. Try adding the "guest" option which will disable password
> >> > prompting.
> >>
> >> Ok, I tried that (debugging output included as well; interestingly
> >> enough, "mount.cifs -V" only outputs the help message, even if
> >> mount.cifs is called with an absolute path). This happenend on a
> >> Debian Lenny system having the shipped kernel version (uname -r):
> >>
> >> 2.6.26-2-686-bigmem
> >>
> >> Since "mount.cifs -V" didn't come up with version info, I used
> >> "apt-cache show smbfs" ("smbfs" is the Debian package mount.cifs is
> >> contained in). It has the same version as the other Samba packages
> >> shipped with Debian: 3.2.5
> >>
> >> ==============
> >>
> >> pia:~# mount -t cifs //server/myuser
> >> /cifs/user --verbose -o
> >> sec=krb5i,user=myuser,guest,iocharset=iso8859-15
> >> parsing options: rw,sec=krb5i,user=myuser,guest,iocharset=iso8859-15
> >>
> >> mount.cifs kernel mount options
> >> unc=//server\myuser,ip=ww.xx.yy.zz,ver=1,rw,sec=krb5i,user=myuser,guest,iocharset=iso8859-15
> >>
> >> mount error 95 = Operation not supported
> >> Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
> >> pia:~# dmesg
> >> [8046556.840192] fs/cifs/cifsfs.c: Devname:
> >> //prag-old.er.heitec.net/hrauch flags: 64
> >> [8046556.847954] fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid:
> >> 15 with uid: 0
> >> [8046556.895920] fs/cifs/connect.c: iocharset set to iso8859-15
> >> [8046556.903932] fs/cifs/connect.c: Username: myuser
> >> [8046556.911928] fs/cifs/connect.c: UNC:
> >> \\server\myuser ip: ww.xx.yy.zz
> >> [8046556.916743] fs/cifs/connect.c: Socket created
> >> [8046556.924050] fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380
> >> rcvtimeo 0x7fffffff
> >> [8046556.935312] fs/cifs/connect.c: Existing smb sess not found
> >> [8046556.935312] fs/cifs/connect.c: Demultiplex PID: 6171
> >> [8046556.946262] fs/cifs/cifssmb.c: secFlags 0x1009
> >> [8046556.950328] fs/cifs/cifssmb.c: Kerberos only mechanism, enable
> >> extended security
> >> [8046556.957962] fs/cifs/transport.c: For smb_command 114
> >> [8046556.962692] fs/cifs/transport.c: Sending smb of length 78
> >> [8046556.968883] fs/cifs/connect.c: rfc1002 length 0xbe
> >> [8046556.974665] fs/cifs/cifssmb.c: Dialect: 2
> >> [8046556.978940] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348
> >> 0x1bb92
> >> [8046556.989230] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
> >> [8046556.991772] fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
> >> [8046556.998296] fs/cifs/asn1.c: Need to call asn1_octets_decode()
> >> function for cifs/server@MYREALM
> >> [8046557.008389] fs/cifs/cifssmb.c: Must sign - secFlags 0x1009
> >> [8046557.015170] CIFS VFS: signing required but server lacks support
> >
> >
> > I think this message explains the problem ^^^^
> >
> > You've request krb5i, but your server doesn't support signing. You
> > might want to try sec=krb5 and see if that works.
>
> That there won't be much security left with sec=krb, because of
> it would lack even signed cisf packets. And as far as I remember,
> the client doesn't do mutual authentication of the server, so
> the server may be faked by any machine registered in the ADS
> domain.
> Any ways, we can use current cifs only to authenticate client
> on the server only, but there won't be much security in the sense
> of transmitted data or checking if we speak with real server.
>

My intention was not to claim that using krb5 instead of krb5i was a
good idea...simply that he might want to try it to make sure that was
the only problem.

Obviously, fixing the server to support signing would be a better
long term solution.

--
Jeff Layton <jlayton@...>
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

Re: Question on current state of sec=krb5*integration in cifs.ko

2009-10-23T09:20:40Z

Hi Volker,

I looked at

http://wiki.samba.org/index.php/UNIX_Extensions

but I couldn't find anything about SMB encryption. Do you have any
good links concerning both SMB signing and encryption (configuring it,
smb.conf options, etc.)?

Are they both part of Samba 3.2.5 (shipped with Debian Lenny) or would
I need a more recent version of Samba?

Volker Lendecke schrieb am Friday, den 23. October 2009:

> [...]
> It's not *as* bad as it sounds security-wise, SMB signing
> attempts to provide integrity, and the Samba extensions for
> SMB encryption (Jeff: Hint...! :-)) would provide
> confidentiality.
>
> Volker

Thanks for enlightening me & kind regards,

Holger

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

signature.asc (204 bytes) Download Attachment

Re: Question on current state of sec=krb5* integration in cifs.ko

2009-10-23T09:00:59Z

On Fri, Oct 23, 2009 at 6:19 PM, Jeff Layton <jlayton@...> wrote:

> On Fri, 23 Oct 2009 15:54:29 +0200
> Holger Rauch <holger.rauch@...> wrote:
>
>> Hi Jeff,
>>
>> first of all, thanks for your quick reply.
>>
>> On Fri, 23 Oct 2009, Jeff Layton wrote:
>>
>> > On Fri, 23 Oct 2009 13:12:14 +0200
>> > Holger Rauch <holger.rauch@...> wrote:
>> > > [...]
>> > > I just tried that. Mount options in /etc/fstab are
>> > >
>> > > noauto,sec=krb5i,iocharset=iso8859-15
>> > >
>> > > When I issue the mount cmd, it asks me for a password.
>> >
>> > That probably means that you have a fairly old mount.cifs program. The
>> > more recent ones don't prompt for a password when sec=krb5* is
>> > specified. Try adding the "guest" option which will disable password
>> > prompting.
>>
>> Ok, I tried that (debugging output included as well; interestingly
>> enough, "mount.cifs -V" only outputs the help message, even if
>> mount.cifs is called with an absolute path). This happenend on a
>> Debian Lenny system having the shipped kernel version (uname -r):
>>
>> 2.6.26-2-686-bigmem
>>
>> Since "mount.cifs -V" didn't come up with version info, I used
>> "apt-cache show smbfs" ("smbfs" is the Debian package mount.cifs is
>> contained in). It has the same version as the other Samba packages
>> shipped with Debian: 3.2.5
>>
>> ==============
>>
>> pia:~# mount -t cifs //server/myuser
>> /cifs/user --verbose -o
>> sec=krb5i,user=myuser,guest,iocharset=iso8859-15
>> parsing options: rw,sec=krb5i,user=myuser,guest,iocharset=iso8859-15
>>
>> mount.cifs kernel mount options
>> unc=//server\myuser,ip=ww.xx.yy.zz,ver=1,rw,sec=krb5i,user=myuser,guest,iocharset=iso8859-15
>>
>> mount error 95 = Operation not supported
>> Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
>> pia:~# dmesg
>> [8046556.840192] fs/cifs/cifsfs.c: Devname:
>> //prag-old.er.heitec.net/hrauch flags: 64
>> [8046556.847954] fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid:
>> 15 with uid: 0
>> [8046556.895920] fs/cifs/connect.c: iocharset set to iso8859-15
>> [8046556.903932] fs/cifs/connect.c: Username: myuser
>> [8046556.911928] fs/cifs/connect.c: UNC:
>> \\server\myuser ip: ww.xx.yy.zz
>> [8046556.916743] fs/cifs/connect.c: Socket created
>> [8046556.924050] fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380
>> rcvtimeo 0x7fffffff
>> [8046556.935312] fs/cifs/connect.c: Existing smb sess not found
>> [8046556.935312] fs/cifs/connect.c: Demultiplex PID: 6171
>> [8046556.946262] fs/cifs/cifssmb.c: secFlags 0x1009
>> [8046556.950328] fs/cifs/cifssmb.c: Kerberos only mechanism, enable
>> extended security
>> [8046556.957962] fs/cifs/transport.c: For smb_command 114
>> [8046556.962692] fs/cifs/transport.c: Sending smb of length 78
>> [8046556.968883] fs/cifs/connect.c: rfc1002 length 0xbe
>> [8046556.974665] fs/cifs/cifssmb.c: Dialect: 2
>> [8046556.978940] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348
>> 0x1bb92
>> [8046556.989230] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
>> [8046556.991772] fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
>> [8046556.998296] fs/cifs/asn1.c: Need to call asn1_octets_decode()
>> function for cifs/server@MYREALM
>> [8046557.008389] fs/cifs/cifssmb.c: Must sign - secFlags 0x1009
>> [8046557.015170] CIFS VFS: signing required but server lacks support
>
>
> I think this message explains the problem ^^^^
>
> You've request krb5i, but your server doesn't support signing. You
> might want to try sec=krb5 and see if that works.

That there won't be much security left with sec=krb, because of
it would lack even signed cisf packets. And as far as I remember,
the client doesn't do mutual authentication of the server, so
the server may be faked by any machine registered in the ADS
domain.
Any ways, we can use current cifs only to authenticate client
on the server only, but there won't be much security in the sense
of transmitted data or checking if we speak with real server.

>> [8046557.022305] fs/cifs/cifssmb.c: negprot rc -95
>> [8046557.136096] fs/cifs/connect.c: No session or bad tcon
>> [8046557.213439] fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid
>> = 15) rc = -95
>> [8046557.221012] CIFS VFS: cifs_mount failed w/return code = -95
>>
>> ==============
>>
>> Do I need a more recent kernel? If so, which one would you recommend?
>>
>> Thanks in advance for any hints & kind regards,
>>
>> Holger
>>
>
>
> --
> Jeff Layton <jlayton@...>
> _______________________________________________
> linux-cifs-client mailing list
> linux-cifs-client@...
> https://lists.samba.org/mailman/listinfo/linux-cifs-client
>

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

Re: Question on current state of sec=krb5* integration in cifs.ko

2009-10-23T09:00:12Z

On Fri, Oct 23, 2009 at 11:55:12AM -0400, Jeff Layton wrote:
> Yes, much...
>
> NFS (well, RPC actually) sends credentials with every call, so if you
> destroy the creds, then the client and server will tend to pick up on
> that fact rather quickly. With CIFS the credentials are just used to
> establish a "session". After that, krb5 doesn't really come into play
> very much (at least until you have to reconnect).

It's not *as* bad as it sounds security-wise, SMB signing
attempts to provide integrity, and the Samba extensions for
SMB encryption (Jeff: Hint...! :-)) would provide
confidentiality.

Volker

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

signature.asc (204 bytes) Download Attachment

Re: Question on current state of sec=krb5* integration in cifs.ko

2009-10-23T08:55:12Z

On Fri, 23 Oct 2009 17:46:02 +0200
Holger Rauch <holger.rauch@...> wrote:

> Hi Jeff,
>
> thanks again for replying that quickly. I tried sec=krb5 and it indeed
> worked (even in conjunction with autofs5). Strangely enough, it even
> continued to work when the credentials cache was empty (having run
> "kdestroy" deliberately in order to test Kerberos security).
>
> I could add files even though there were no tickets left in the cache.
> This shouldn't be the case, I think (at least that's how it works on
> NFSv4; i.e. on NFSv4 I would get "permission denied" when tickets are
> either expired or not present). Is CIFS different in this regard?
>

Yes, much...

NFS (well, RPC actually) sends credentials with every call, so if you
destroy the creds, then the client and server will tend to pick up on
that fact rather quickly. With CIFS the credentials are just used to
establish a "session". After that, krb5 doesn't really come into play
very much (at least until you have to reconnect).

--
Jeff Layton <jlayton@...>

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

signature.asc (205 bytes) Download Attachment

Re: Question on current state of sec=krb5* integration in cifs.ko

2009-10-23T08:46:02Z

Hi Jeff,

thanks again for replying that quickly. I tried sec=krb5 and it indeed
worked (even in conjunction with autofs5). Strangely enough, it even
continued to work when the credentials cache was empty (having run
"kdestroy" deliberately in order to test Kerberos security).

I could add files even though there were no tickets left in the cache.
This shouldn't be the case, I think (at least that's how it works on
NFSv4; i.e. on NFSv4 I would get "permission denied" when tickets are
either expired or not present). Is CIFS different in this regard?

On Fri, 23 Oct 2009, Jeff Layton wrote:

> [...]
> > [8046557.008389] fs/cifs/cifssmb.c: Must sign - secFlags 0x1009
> > [8046557.015170] CIFS VFS: signing required but server lacks support
>
>
> I think this message explains the problem ^^^^
>
> You've request krb5i, but your server doesn't support signing. You
> might want to try sec=krb5 and see if that works.

What exactly is meant by "server" (Samba software, MIT Kerberos
software, etc.)? Do I need a more recent Samba, MIT Kerberos, anything
else?

Thanks again & kind regards,

Holger

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

signature.asc (204 bytes) Download Attachment

Re: Question on current state of sec=krb5* integration in cifs.ko

2009-10-23T07:19:42Z

On Fri, 23 Oct 2009 15:54:29 +0200
Holger Rauch <holger.rauch@...> wrote:

> Hi Jeff,
>
> first of all, thanks for your quick reply.
>
> On Fri, 23 Oct 2009, Jeff Layton wrote:
>
> > On Fri, 23 Oct 2009 13:12:14 +0200
> > Holger Rauch <holger.rauch@...> wrote:
> > > [...]
> > > I just tried that. Mount options in /etc/fstab are
> > >
> > > noauto,sec=krb5i,iocharset=iso8859-15
> > >
> > > When I issue the mount cmd, it asks me for a password.
> >
> > That probably means that you have a fairly old mount.cifs program. The
> > more recent ones don't prompt for a password when sec=krb5* is
> > specified. Try adding the "guest" option which will disable password
> > prompting.
>
> Ok, I tried that (debugging output included as well; interestingly
> enough, "mount.cifs -V" only outputs the help message, even if
> mount.cifs is called with an absolute path). This happenend on a
> Debian Lenny system having the shipped kernel version (uname -r):
>
> 2.6.26-2-686-bigmem
>
> Since "mount.cifs -V" didn't come up with version info, I used
> "apt-cache show smbfs" ("smbfs" is the Debian package mount.cifs is
> contained in). It has the same version as the other Samba packages
> shipped with Debian: 3.2.5
>
> ==============
>
> pia:~# mount -t cifs //server/myuser
> /cifs/user --verbose -o
> sec=krb5i,user=myuser,guest,iocharset=iso8859-15
> parsing options: rw,sec=krb5i,user=myuser,guest,iocharset=iso8859-15
>
> mount.cifs kernel mount options
> unc=//server\myuser,ip=ww.xx.yy.zz,ver=1,rw,sec=krb5i,user=myuser,guest,iocharset=iso8859-15
>
> mount error 95 = Operation not supported
> Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
> pia:~# dmesg
> [8046556.840192] fs/cifs/cifsfs.c: Devname:
> //prag-old.er.heitec.net/hrauch flags: 64
> [8046556.847954] fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid:
> 15 with uid: 0
> [8046556.895920] fs/cifs/connect.c: iocharset set to iso8859-15
> [8046556.903932] fs/cifs/connect.c: Username: myuser
> [8046556.911928] fs/cifs/connect.c: UNC:
> \\server\myuser ip: ww.xx.yy.zz
> [8046556.916743] fs/cifs/connect.c: Socket created
> [8046556.924050] fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380
> rcvtimeo 0x7fffffff
> [8046556.935312] fs/cifs/connect.c: Existing smb sess not found
> [8046556.935312] fs/cifs/connect.c: Demultiplex PID: 6171
> [8046556.946262] fs/cifs/cifssmb.c: secFlags 0x1009
> [8046556.950328] fs/cifs/cifssmb.c: Kerberos only mechanism, enable
> extended security
> [8046556.957962] fs/cifs/transport.c: For smb_command 114
> [8046556.962692] fs/cifs/transport.c: Sending smb of length 78
> [8046556.968883] fs/cifs/connect.c: rfc1002 length 0xbe
> [8046556.974665] fs/cifs/cifssmb.c: Dialect: 2
> [8046556.978940] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348
> 0x1bb92
> [8046556.989230] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
> [8046556.991772] fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
> [8046556.998296] fs/cifs/asn1.c: Need to call asn1_octets_decode()
> function for cifs/server@MYREALM
> [8046557.008389] fs/cifs/cifssmb.c: Must sign - secFlags 0x1009
> [8046557.015170] CIFS VFS: signing required but server lacks support

I think this message explains the problem ^^^^

You've request krb5i, but your server doesn't support signing. You
might want to try sec=krb5 and see if that works.

> [8046557.022305] fs/cifs/cifssmb.c: negprot rc -95
> [8046557.136096] fs/cifs/connect.c: No session or bad tcon
> [8046557.213439] fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid
> = 15) rc = -95
> [8046557.221012] CIFS VFS: cifs_mount failed w/return code = -95
>
> ==============
>
> Do I need a more recent kernel? If so, which one would you recommend?
>
> Thanks in advance for any hints & kind regards,
>
> Holger
>

--
Jeff Layton <jlayton@...>
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

Re: Question on current state of sec=krb5* integration in cifs.ko

2009-10-23T06:54:29Z

Hi Jeff,

first of all, thanks for your quick reply.

On Fri, 23 Oct 2009, Jeff Layton wrote:

> On Fri, 23 Oct 2009 13:12:14 +0200
> Holger Rauch <holger.rauch@...> wrote:
> > [...]
> > I just tried that. Mount options in /etc/fstab are
> >
> > noauto,sec=krb5i,iocharset=iso8859-15
> >
> > When I issue the mount cmd, it asks me for a password.
>
> That probably means that you have a fairly old mount.cifs program. The
> more recent ones don't prompt for a password when sec=krb5* is
> specified. Try adding the "guest" option which will disable password
> prompting.

Ok, I tried that (debugging output included as well; interestingly
enough, "mount.cifs -V" only outputs the help message, even if
mount.cifs is called with an absolute path). This happenend on a
Debian Lenny system having the shipped kernel version (uname -r):

2.6.26-2-686-bigmem

Since "mount.cifs -V" didn't come up with version info, I used
"apt-cache show smbfs" ("smbfs" is the Debian package mount.cifs is
contained in). It has the same version as the other Samba packages
shipped with Debian: 3.2.5

==============

pia:~# mount -t cifs //server/myuser
/cifs/user --verbose -o
sec=krb5i,user=myuser,guest,iocharset=iso8859-15
parsing options: rw,sec=krb5i,user=myuser,guest,iocharset=iso8859-15

mount.cifs kernel mount options
unc=//server\myuser,ip=ww.xx.yy.zz,ver=1,rw,sec=krb5i,user=myuser,guest,iocharset=iso8859-15

mount error 95 = Operation not supported
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
pia:~# dmesg
[8046556.840192] fs/cifs/cifsfs.c: Devname:
//prag-old.er.heitec.net/hrauch flags: 64
[8046556.847954] fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid:
15 with uid: 0
[8046556.895920] fs/cifs/connect.c: iocharset set to iso8859-15
[8046556.903932] fs/cifs/connect.c: Username: myuser
[8046556.911928] fs/cifs/connect.c: UNC:
\\server\myuser ip: ww.xx.yy.zz
[8046556.916743] fs/cifs/connect.c: Socket created
[8046556.924050] fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380
rcvtimeo 0x7fffffff
[8046556.935312] fs/cifs/connect.c: Existing smb sess not found
[8046556.935312] fs/cifs/connect.c: Demultiplex PID: 6171
[8046556.946262] fs/cifs/cifssmb.c: secFlags 0x1009
[8046556.950328] fs/cifs/cifssmb.c: Kerberos only mechanism, enable
extended security
[8046556.957962] fs/cifs/transport.c: For smb_command 114
[8046556.962692] fs/cifs/transport.c: Sending smb of length 78
[8046556.968883] fs/cifs/connect.c: rfc1002 length 0xbe
[8046556.974665] fs/cifs/cifssmb.c: Dialect: 2
[8046556.978940] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348
0x1bb92
[8046556.989230] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
[8046556.991772] fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
[8046556.998296] fs/cifs/asn1.c: Need to call asn1_octets_decode()
function for cifs/server@MYREALM
[8046557.008389] fs/cifs/cifssmb.c: Must sign - secFlags 0x1009
[8046557.015170] CIFS VFS: signing required but server lacks support
[8046557.022305] fs/cifs/cifssmb.c: negprot rc -95
[8046557.136096] fs/cifs/connect.c: No session or bad tcon
[8046557.213439] fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid
= 15) rc = -95
[8046557.221012] CIFS VFS: cifs_mount failed w/return code = -95

==============

Do I need a more recent kernel? If so, which one would you recommend?

Thanks in advance for any hints & kind regards,

Holger

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

signature.asc (204 bytes) Download Attachment

Re: Manual page for mount.cifs credentials option

2009-10-23T05:16:22Z

On Thu, 22 Oct 2009 12:49:05 -0400
Scott Lovenberg <scott.lovenberg@...> wrote:

> Not sure if this is the correct place to file this report, if not, please point me in the correct direction.
>
> The credentials option for mount.smbfs used to be the following format:
> user=name
> password=pass
>
> I've found that the format supported for mount.cifs is:
> username=name
> password=pass
>
> This seems at odds with the manual page for mount.cifs under the user=arg option:
> [...]
> Note
> The cifs vfs accepts the parameter user=, or for users familiar with smbfs it
> accepts the longer form of the parameter username=. Similarly the longer smbfs
> style parameter names may be accepted as synonyms for the shorter cifs
> parameters pass=,dom= and cred=.
> [...]
>
> I had, for whatever reason, assumed that the user option rules would apply to the credentials file or that it would be backwards compatible with the older mount.smbfs credentials file format. Are either of these assumptions correct? If not, would it make sense to add or reword the manual page a bit (assuming I'm not the only one that misinterpreted it) for clarity? I wouldn't mind drafting up a proposal if other felt it was worth the effort.
>
>
> Happy Version Numbers:
> from The Fine Manual page for mount.cifs(8)
> VERSION
> This man page is correct for version 1.52 of the cifs vfs filesystem (roughly Linux kernel 2.6.24).
> [1005 12:24 sun ~]#smbd -V
> Version 3.0.33-3.7.el5
> [1007 12:26 sun ~]#uname -a
> Linux sanitized.network.tld 2.6.18-92.1.22.el5.centos.plusxen #1 SMP Wed Dec 17 11:22:13 EST 2008 x86_64 x86_64 x86_64 GNU/Linux

Consistency here would probably be a good thing. A proposal for
cleaning it up would be welcome. Patches would be even better.

--
Jeff Layton <jlayton@...>
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

Re: Question on current state of sec=krb5* integration in cifs.ko

2009-10-23T04:17:31Z

On Fri, 23 Oct 2009 13:12:14 +0200
Holger Rauch <holger.rauch@...> wrote:

> Hi Robert,
>
> Robert Euhus schrieb am Friday, den 23. October 2009:
>
> > [...]
> > It works here on Lenny, although you might have to install the keyutils
> > Package and add the following lines to /etc/request-key.conf :
> >
> > create cifs.spnego * * /usr/sbin/cifs.upcall %k %d
> > create dns_resolver * * /usr/sbin/cifs.upcall %k
>
> I just tried that. Mount options in /etc/fstab are
>
> noauto,sec=krb5i,iocharset=iso8859-15
>
> When I issue the mount cmd, it asks me for a password.

That probably means that you have a fairly old mount.cifs program. The
more recent ones don't prompt for a password when sec=krb5* is
specified. Try adding the "guest" option which will disable password
prompting.

> Is there any
> way to get more debugging info from the mount.cifs cmd and the CIFS
> VFS kernel module? (I was checking /var/log/syslog, /var/log/messages,
> /var/log/daemon.log, but found nothing that could be helpful).
>

Yes, see:

http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting

> Like I mentioned, kerberized smbclient sessions work as expected (i.e.
> I'm *not* asked for a password; just as it's supposed to be). I do get
> a valid Kerberos ticket for cifs, as shown in this output from "klist
> -5f":
>
> ==========
>
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: user@MYREALM
>
> Valid starting Expires Service principal
> 10/23/09 12:31:13 10/24/09 04:31:13 krbtgt/MYREALM@MYREALM
> renew until 10/24/09 12:30:51, Flags: FRIAT
> 10/23/09 12:40:42 10/24/09 04:31:13
> cifs/sambaserver.mydomain@MYREALM
> renew until 10/24/09
> 12:30:51, Flags: FRAT
>
> ==========
>
> I should perhaps also mention that my LDAP accounts were created using
> Debian Lenny's ldapscripts package before I installed Samba and used
> ldapsam:editposix. Samba's LDAP stuff was initialized using "net sam
> provision"; as described in
>
> http://wiki.samba.org/index.php/Ldapsam_Editposix
>
> So, the Kerberos user named "user" doesn't have the
> samba* attributes set in the LDAP database yet. But since that didn't
> seem to matter for smbclient sessions, it also shouldn't matter for
> mount.cifs, should it?
>
> In addition, my Kerberos database is stored in the
> same OpenLDAP database as the user accounts are, just below a
> different ou. (But that shouldn't matter since smbclient works, so the
> LDAP lookup itself shouldn't be the problem).
>
> > You might also want to have a look at a small (and not quite finished
> > yet) German HOWTO I wrote:
> >
> > http://www.rrzn.uni-hannover.de/anl-linclient-ads.html
>
> Thanks for mentioning this, but I have MIT Kerberos installed on a
> Debian Lenny machine acting as KDC. Nevertheless, still helpful for AD
> integration.
>
> The main difference compared to your setup is that my server is
> actually a Samba server running on a Debian Lenny system and I'm
> trying to mount a cifs fs on a Linux client (i.e. a Linux machine
> pretending to be a Windows client). Do I need the winbindd also on the
> client machine in such a scenario (your HOWTO suggests running in on the
> client, but you are authenticating against a "real" AD on a Windows
> server; I'm authenticating against OpenLDAP+MIT Kerberos+Samba on a Debian
> Lenny system)?
>
> (In case you need more info, I will of course try provide it).
>
> Thanks in advance for any hints & kind regards,
>
> Holger
>

--
Jeff Layton <jlayton@...>

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

signature.asc (205 bytes) Download Attachment

Re: Question on current state of sec=krb5* integration in cifs.ko

2009-10-23T04:12:14Z

Hi Robert,

Robert Euhus schrieb am Friday, den 23. October 2009:

> [...]
> It works here on Lenny, although you might have to install the keyutils
> Package and add the following lines to /etc/request-key.conf :
>
> create cifs.spnego * * /usr/sbin/cifs.upcall %k %d
> create dns_resolver * * /usr/sbin/cifs.upcall %k

I just tried that. Mount options in /etc/fstab are

noauto,sec=krb5i,iocharset=iso8859-15

When I issue the mount cmd, it asks me for a password. Is there any
way to get more debugging info from the mount.cifs cmd and the CIFS
VFS kernel module? (I was checking /var/log/syslog, /var/log/messages,
/var/log/daemon.log, but found nothing that could be helpful).

Like I mentioned, kerberized smbclient sessions work as expected (i.e.
I'm *not* asked for a password; just as it's supposed to be). I do get
a valid Kerberos ticket for cifs, as shown in this output from "klist
-5f":

==========

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: user@MYREALM

Valid starting Expires Service principal
10/23/09 12:31:13 10/24/09 04:31:13 krbtgt/MYREALM@MYREALM
renew until 10/24/09 12:30:51, Flags: FRIAT
10/23/09 12:40:42 10/24/09 04:31:13
cifs/sambaserver.mydomain@MYREALM
renew until 10/24/09
12:30:51, Flags: FRAT

==========

I should perhaps also mention that my LDAP accounts were created using
Debian Lenny's ldapscripts package before I installed Samba and used
ldapsam:editposix. Samba's LDAP stuff was initialized using "net sam
provision"; as described in

http://wiki.samba.org/index.php/Ldapsam_Editposix

So, the Kerberos user named "user" doesn't have the
samba* attributes set in the LDAP database yet. But since that didn't
seem to matter for smbclient sessions, it also shouldn't matter for
mount.cifs, should it?

In addition, my Kerberos database is stored in the
same OpenLDAP database as the user accounts are, just below a
different ou. (But that shouldn't matter since smbclient works, so the
LDAP lookup itself shouldn't be the problem).

> You might also want to have a look at a small (and not quite finished
> yet) German HOWTO I wrote:
>
> http://www.rrzn.uni-hannover.de/anl-linclient-ads.html

Thanks for mentioning this, but I have MIT Kerberos installed on a
Debian Lenny machine acting as KDC. Nevertheless, still helpful for AD
integration.

The main difference compared to your setup is that my server is
actually a Samba server running on a Debian Lenny system and I'm
trying to mount a cifs fs on a Linux client (i.e. a Linux machine
pretending to be a Windows client). Do I need the winbindd also on the
client machine in such a scenario (your HOWTO suggests running in on the
client, but you are authenticating against a "real" AD on a Windows
server; I'm authenticating against OpenLDAP+MIT Kerberos+Samba on a Debian
Lenny system)?

(In case you need more info, I will of course try provide it).

Thanks in advance for any hints & kind regards,

Holger

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

signature.asc (204 bytes) Download Attachment

Re: Question on current state of sec=krb5* integration in cifs.ko

2009-10-23T01:00:46Z

Hi,

Holger Rauch wrote:

> Hi to everybody,
>
> I came accross this link
>
> http://fixunix.com/samba/140566-samba-mount-cifs-sec-krb5.html
>
> while trying to use sec=krb5 or sec=krb5i in conjunction with
> mount.cifs. On a Debian Lenny system (includes version 1.53 of
> cifs.ko), this doesn't seem to work. This thread is quite old
> (10/2007) and I'm wondering whether what's been said in there is still
> valid.
>
> "smbclient -L ... -k" or "smbclient ... -k" calls work without any
> problems (provided that I run "kinit" in advance). In the interactive
> smb shell, I can use e.g. mkdir and rmdir without any problem. So, my
> Kerberos setup is working.
>
> Installed kernel image on Debian Lenny is ("uname -r" output):
>
> 2.6.26-2-686-bigmem
>
> What's the current status regarding sec=krb5 and sec=krb5i mount
> options?
>

It works here on Lenny, although you might have to install the keyutils
Package and add the following lines to /etc/request-key.conf :

create cifs.spnego * * /usr/sbin/cifs.upcall %k %d
create dns_resolver * * /usr/sbin/cifs.upcall %k

You might also want to have a look at a small (and not quite finished
yet) German HOWTO I wrote:

http://www.rrzn.uni-hannover.de/anl-linclient-ads.html

> Thanks in advance for any info!
>
> Kind regards,
>
> Holger
> --
> =========================================
> Holger Rauch
> Entwicklung Anwendungs-Software
> Systemadministration UNIX
>
> Tel.: +49 / 9131 / 877 - 141
> Fax: +49 / 9131 / 877 - 266
> Email: Holger.Rauch@...
> =========================================
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> linux-cifs-client mailing list
> linux-cifs-client@...
> https://lists.samba.org/mailman/listinfo/linux-cifs-client

Yours,
Robert
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client