Nabble - Samba - linux-cifs-client

Re: [PATCH] add check for nameidata before accessing it

2009-11-19T14:12:42Z

On Thu, 19 Nov 2009 15:05:45 -0600
Shirish Pargaonkar <shirishpargaonkar@...> wrote:

> This should prevent oops reported in kernel bugzilla 14641
>
> From 240f75430dbe4965f79d903309488ebabd3d3625 Mon Sep 17 00:00:00 2001
> From: Shirish Pargaonkar <shirishpargaonkar@...>
> Date: Thu, 19 Nov 2009 14:38:59 -0600
> Subject: [PATCH] add check for nameidata before accessing it
>
> Cc: Stable <stable@...>
> ---
> fs/cifs/dir.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/cifs/dir.c b/fs/cifs/dir.c
> index 627a60a..32771f5 100644
> --- a/fs/cifs/dir.c
> +++ b/fs/cifs/dir.c
> @@ -643,7 +643,7 @@ cifs_lookup(struct inode *parent_dir_inode, struct
> dentry *direntry,
> * O_EXCL: optimize away the lookup, but don't hash the dentry. Let
> * the VFS handle the create.
> */
> - if (nd->flags & LOOKUP_EXCL) {
> + if (nd && (nd->flags & LOOKUP_EXCL)) {
> d_instantiate(direntry, NULL);
> return 0;
> }
> @@ -675,7 +675,7 @@ cifs_lookup(struct inode *parent_dir_inode, struct
> dentry *direntry,
> * reduction in network traffic in the other paths.
> */
> if (pTcon->unix_ext) {
> - if (!(nd->flags & (LOOKUP_PARENT | LOOKUP_DIRECTORY)) &&
> + if (nd && !(nd->flags & (LOOKUP_PARENT | LOOKUP_DIRECTORY)) &&
> (nd->flags & LOOKUP_OPEN) && !pTcon->broken_posix_open &&
> (nd->intent.open.flags & O_CREAT)) {
> rc = cifs_posix_open(full_path, &newInode, nd->path.mnt,
> --
> 1.6.0.2

Once the line-wrapping is fixed...

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

[PATCH] add check for nameidata before accessing it

2009-11-19T13:05:45Z

This should prevent oops reported in kernel bugzilla 14641

From 240f75430dbe4965f79d903309488ebabd3d3625 Mon Sep 17 00:00:00 2001
From: Shirish Pargaonkar <shirishpargaonkar@...>
Date: Thu, 19 Nov 2009 14:38:59 -0600
Subject: [PATCH] add check for nameidata before accessing it

Cc: Stable <stable@...>
---
fs/cifs/dir.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/cifs/dir.c b/fs/cifs/dir.c
index 627a60a..32771f5 100644
--- a/fs/cifs/dir.c
+++ b/fs/cifs/dir.c
@@ -643,7 +643,7 @@ cifs_lookup(struct inode *parent_dir_inode, struct
dentry *direntry,
* O_EXCL: optimize away the lookup, but don't hash the dentry. Let
* the VFS handle the create.
*/
- if (nd->flags & LOOKUP_EXCL) {
+ if (nd && (nd->flags & LOOKUP_EXCL)) {
d_instantiate(direntry, NULL);
return 0;
}
@@ -675,7 +675,7 @@ cifs_lookup(struct inode *parent_dir_inode, struct
dentry *direntry,
* reduction in network traffic in the other paths.
*/
if (pTcon->unix_ext) {
- if (!(nd->flags & (LOOKUP_PARENT | LOOKUP_DIRECTORY)) &&
+ if (nd && !(nd->flags & (LOOKUP_PARENT | LOOKUP_DIRECTORY)) &&
(nd->flags & LOOKUP_OPEN) && !pTcon->broken_posix_open &&
(nd->intent.open.flags & O_CREAT)) {
rc = cifs_posix_open(full_path, &newInode, nd->path.mnt,
--
1.6.0.2

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

cifs.nd.2.patch (1K) Download Attachment

Re: [PATCH 6/7] cifs: Don't use PF_MEMALLOC

2009-11-17T08:40:49Z

It is hard to follow exactly what this flag does in /mm (other than try harder on memory allocations) - I haven't found much about this flag (e.g. http://lwn.net/Articles/246928/) but it does look like most of the fs no longer set this (except xfs) e.g. ext3_ordered_writepage. When running out of memory in the cifs_demultiplex_thread it will retry 3 seconds later, but if memory allocations ever fail in this path we could potentially be holding up (an already issued write in) writepages for that period by not having memory to get the response to see if the write succeeded.

We pass in few flags for these memory allocation requests: GFP_NOFS (on the mempool_alloc) and SLAB_HWCACHE_ALIGN (on the kmem_cache_create of the pool) should we be passing in other flags on the allocations?

On Tue, Nov 17, 2009 at 6:47 AM, Jeff Layton <jlayton@...> wrote:

On Tue, 17 Nov 2009 16:22:32 +0900 (JST)
KOSAKI Motohiro <kosaki.motohiro@...> wrote:

>
> Non MM subsystem must not use PF_MEMALLOC. Memory reclaim need few
> memory, anyone must not prevent it. Otherwise the system cause
> mysterious hang-up and/or OOM Killer invokation.
>
> Cc: Steve French <sfrench@...>
> Cc: linux-cifs-client@...
> Cc: samba-technical@...
> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@...>
> ---
> fs/cifs/connect.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> index 63ea83f..f9b1553 100644
> --- a/fs/cifs/connect.c
> +++ b/fs/cifs/connect.c
> @@ -337,7 +337,6 @@ cifs_demultiplex_thread(struct TCP_Server_Info *server)
> bool isMultiRsp;
> int reconnect;
>
> - current->flags |= PF_MEMALLOC;
> cFYI(1, ("Demultiplex PID: %d", task_pid_nr(current)));
>
> length = atomic_inc_return(&tcpSesAllocCount);

This patch appears to be safe for CIFS. I believe that the demultiplex
thread only does mempool allocations currently. The only other case
where it did an allocation was recently changed with the conversion of
the oplock break code to use slow_work.

Barring anything I've missed...

Acked-by: Jeff Layton <jlayton@...>

--
Thanks,

Steve

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

Re: [PATCH 6/7] cifs: Don't use PF_MEMALLOC

2009-11-17T04:47:39Z

On Tue, 17 Nov 2009 16:22:32 +0900 (JST)
KOSAKI Motohiro <kosaki.motohiro@...> wrote:

>
> Non MM subsystem must not use PF_MEMALLOC. Memory reclaim need few
> memory, anyone must not prevent it. Otherwise the system cause
> mysterious hang-up and/or OOM Killer invokation.
>
> Cc: Steve French <sfrench@...>
> Cc: linux-cifs-client@...
> Cc: samba-technical@...
> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@...>
> ---
> fs/cifs/connect.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> index 63ea83f..f9b1553 100644
> --- a/fs/cifs/connect.c
> +++ b/fs/cifs/connect.c
> @@ -337,7 +337,6 @@ cifs_demultiplex_thread(struct TCP_Server_Info *server)
> bool isMultiRsp;
> int reconnect;
>
> - current->flags |= PF_MEMALLOC;
> cFYI(1, ("Demultiplex PID: %d", task_pid_nr(current)));
>
> length = atomic_inc_return(&tcpSesAllocCount);

This patch appears to be safe for CIFS. I believe that the demultiplex
thread only does mempool allocations currently. The only other case
where it did an allocation was recently changed with the conversion of
the oplock break code to use slow_work.

Barring anything I've missed...

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

Re: [PATCH] cifs: clear server inode number flag while autodisabling

2009-11-16T07:25:01Z

Merged into cifs-2.6.git

Will request upstream later today.

On Mon, Nov 16, 2009 at 7:42 AM, Suresh Jayaraman <sjayaraman@...> wrote:

On 11/16/2009 07:10 PM, Jeff Layton wrote:
> On Mon, 16 Nov 2009 07:39:43 -0500
> Jeff Layton <jlayton@...> wrote:
>
>> On Mon, 16 Nov 2009 12:03:16 +0530
>> Suresh Jayaraman <sjayaraman@...> wrote:
>>
>>> Fix the commit ec06aedd44 that intended to turn off querying for server inode
>>> numbers when server doesn't consistently support inode numbers. Presumably
>>> the commit didn't actually clear the CIFS_MOUNT_SERVER_INUM flag, perhaps a
>>> typo.
>>>
>>> Signed-off-by: Suresh Jayaraman <sjayaraman@...>
>>> Cc: Jeff Layton <jlayton@...>
>>> ---
>>> fs/cifs/misc.c | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/fs/cifs/misc.c b/fs/cifs/misc.c
>>> index 1e25efc..d27d4ec 100644
>>> --- a/fs/cifs/misc.c
>>> +++ b/fs/cifs/misc.c
>>> @@ -720,7 +720,7 @@ 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;
>>> + 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 "
>>
>> Doh! Boneheaded error...
>>
>> Acked-by: Jeff Layton <jlayton@...>
>
>
> This patch probably needs to go to 2.6.32 and -stable.
>

Ah, yes, please include -Cc stable.

Cc: Stable <stable@...>

Thanks,

--
Suresh Jayaraman

--
Thanks,

Steve

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

Re: [PATCH] cifs: clear server inode number flag while autodisabling

2009-11-16T05:42:41Z

On 11/16/2009 07:10 PM, Jeff Layton wrote:

> On Mon, 16 Nov 2009 07:39:43 -0500
> Jeff Layton <jlayton@...> wrote:
>
>> On Mon, 16 Nov 2009 12:03:16 +0530
>> Suresh Jayaraman <sjayaraman@...> wrote:
>>
>>> Fix the commit ec06aedd44 that intended to turn off querying for server inode
>>> numbers when server doesn't consistently support inode numbers. Presumably
>>> the commit didn't actually clear the CIFS_MOUNT_SERVER_INUM flag, perhaps a
>>> typo.
>>>
>>> Signed-off-by: Suresh Jayaraman <sjayaraman@...>
>>> Cc: Jeff Layton <jlayton@...>
>>> ---
>>> fs/cifs/misc.c | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/fs/cifs/misc.c b/fs/cifs/misc.c
>>> index 1e25efc..d27d4ec 100644
>>> --- a/fs/cifs/misc.c
>>> +++ b/fs/cifs/misc.c
>>> @@ -720,7 +720,7 @@ 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;
>>> + 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 "
>>
>> Doh! Boneheaded error...
>>
>> Acked-by: Jeff Layton <jlayton@...>
>
>
> This patch probably needs to go to 2.6.32 and -stable.
>

Ah, yes, please include -Cc stable.

Cc: Stable <stable@...>

Thanks,

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

Re: [PATCH] cifs: clear server inode number flag while autodisabling

2009-11-16T05:40:28Z

On Mon, 16 Nov 2009 07:39:43 -0500
Jeff Layton <jlayton@...> wrote:

> On Mon, 16 Nov 2009 12:03:16 +0530
> Suresh Jayaraman <sjayaraman@...> wrote:
>
> > Fix the commit ec06aedd44 that intended to turn off querying for server inode
> > numbers when server doesn't consistently support inode numbers. Presumably
> > the commit didn't actually clear the CIFS_MOUNT_SERVER_INUM flag, perhaps a
> > typo.
> >
> > Signed-off-by: Suresh Jayaraman <sjayaraman@...>
> > Cc: Jeff Layton <jlayton@...>
> > ---
> > fs/cifs/misc.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/fs/cifs/misc.c b/fs/cifs/misc.c
> > index 1e25efc..d27d4ec 100644
> > --- a/fs/cifs/misc.c
> > +++ b/fs/cifs/misc.c
> > @@ -720,7 +720,7 @@ 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;
> > + 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 "
>
> Doh! Boneheaded error...
>
> Acked-by: Jeff Layton <jlayton@...>

This patch probably needs to go to 2.6.32 and -stable.

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

Re: [PATCH] cifs: clear server inode number flag while autodisabling

2009-11-16T04:39:43Z

On Mon, 16 Nov 2009 12:03:16 +0530
Suresh Jayaraman <sjayaraman@...> wrote:

> Fix the commit ec06aedd44 that intended to turn off querying for server inode
> numbers when server doesn't consistently support inode numbers. Presumably
> the commit didn't actually clear the CIFS_MOUNT_SERVER_INUM flag, perhaps a
> typo.
>
> Signed-off-by: Suresh Jayaraman <sjayaraman@...>
> Cc: Jeff Layton <jlayton@...>
> ---
> fs/cifs/misc.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/fs/cifs/misc.c b/fs/cifs/misc.c
> index 1e25efc..d27d4ec 100644
> --- a/fs/cifs/misc.c
> +++ b/fs/cifs/misc.c
> @@ -720,7 +720,7 @@ 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;
> + 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 "

Doh! Boneheaded error...

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

[PATCH] cifs: clear server inode number flag while autodisabling

2009-11-15T22:33:16Z

Fix the commit ec06aedd44 that intended to turn off querying for server inode
numbers when server doesn't consistently support inode numbers. Presumably
the commit didn't actually clear the CIFS_MOUNT_SERVER_INUM flag, perhaps a
typo.

Signed-off-by: Suresh Jayaraman <sjayaraman@...>
Cc: Jeff Layton <jlayton@...>
---
fs/cifs/misc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/cifs/misc.c b/fs/cifs/misc.c
index 1e25efc..d27d4ec 100644
--- a/fs/cifs/misc.c
+++ b/fs/cifs/misc.c
@@ -720,7 +720,7 @@ 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;
+ 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 "
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

Re: File Creation Time

2009-11-12T10:10:59Z

On Thu, 2009-11-12 at 10:29 -0500, Jeff Layton wrote:

> On Wed, 11 Nov 2009 17:12:08 -0800
> Sam Flory <sam.flory@...> wrote:
>
> > Is there a way to get creation time for a file on a windows cifs server?
> > If yes is there a command or system call to get it?
> >
>
> Not currently, no. CreationTime in the returned attributes are pretty
> much ignored, primarily because we don't have a place to put in in the
> POSIX stat struct.
>
> You could maybe consider doing something like faking up an xattr with
> that info, but the code for that doesn't exist today.
>

Thanks Jeff that's very useful info. I'll look into that, but I'm not
sure it's worth supporting yet another hack of a patch in our kernel.

Ps- Thanks everyone. We've really been pleased with the stability, and
compatibility of the cifs driver.

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

Re: File Creation Time

2009-11-12T07:29:19Z

On Wed, 11 Nov 2009 17:12:08 -0800
Sam Flory <sam.flory@...> wrote:

> Is there a way to get creation time for a file on a windows cifs server?
> If yes is there a command or system call to get it?
>

Not currently, no. CreationTime in the returned attributes are pretty
much ignored, primarily because we don't have a place to put in in the
POSIX stat struct.

You could maybe consider doing something like faking up an xattr with
that info, but the code for that doesn't exist today.

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

File Creation Time

2009-11-11T17:12:08Z

Is there a way to get creation time for a file on a windows cifs server?
If yes is there a command or system call to get it?

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

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

2009-11-09T06:22:53Z

Hi Jeff,

Thanks for the reply.

It does look like that when I take away the carriage return in line of
password in my "credentials" file,
mounting works ! That's my "work-around" for the time being.

Kin

Jeff Layton wrote:

> On Sun, 08 Nov 2009 13:18:50 -0500
> Kin Yip <kinyip@...> wrote:
>
>
>> 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 ???
>>
>
> Known regression. mount.cifs isn't stripping the trailing "\n" off of
> the password in cred files. We'll be shipping a fixed package for RHEL
> soon.
>
>

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

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

2009-11-09T04:04:21Z

On Sun, 08 Nov 2009 13:18:50 -0500
Kin Yip <kinyip@...> wrote:

> 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 ???

Known regression. mount.cifs isn't stripping the trailing "\n" off of
the password in cred files. We'll be shipping a fixed package for RHEL
soon.

--
Jeff Layton <jlayton@...>
_______________________________________________
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-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