Wilhelm Meier | 1 Jul 2005 15:02
Picon

pam_cifs: Linux-PAM for mounting/unmounting cifs shares

Hello everybody,

I wrote a simple Linux-PAM module named pam_cifs which is of special interest 
to all linux-cifs-client users:

http://sourceforge.net/projects/pam-cifs

pam_cifs is responsible for mounting cifs-shares on login of users to the 
system. It is really usefull in combination with pam_ldap and nss_ldap. The 
unmounting of cifs-shares is done via a little daemon, to ensure, that the 
filesystem isn't in use anymore.

This is a very (!) early state of this project, but it works. Compared to 
pam_mount this module is much, much simpler and has a different architecture 
and its limitations.

Kind regards,

Wilhelm Meier
email: meier <at> informatik.fh-kl.de
a.nielsen | 6 Jul 2005 04:20
Picon
Picon

How to stop cifs from printing passwords to the console?

Hi,

I've just realised that although my CIFS passwords are stored in a
relatively secure credentials file, when the CIFS filesystems are mounted
during boot the full list of mount options is printed on the screen, which
includes usernames and passwords extracted from the credentials file.  This
means anyone who happens to be watching the machine during boot can see the
passwords.

Is there some way to prevent this from happening?  I don't recall compiling
extra debug output into the module.

Thanks,
Adam.
Javier de Pedro | 6 Jul 2005 17:52

UTF-8 filenames

Hello.

I want to use CIFS with UTF-8 filenames. I have a shared directory in
Windows XP with filenames in russian and chinese.

I have two Linux PC:

PC 1
	ubuntu 5.04 (kernel 2.5.10-5 i686, samba 3.0.10)

PC 2
	redhat 9.0 (kernel 2.4.20-8 i686)
	kernel patched with cifs-1.20c-2.4.tar.gz
	cifs compiled into the kernel (not as a module)
	mount.cifs compiled from samba 3.0.14a.tar.gz

In PC1, if I mount the shared directory with:

>mount -t cifs //10.0.0.89/TestUnicode
unicode -ouser=linux,password=linux,iocharset=utf8

then I execute 'ls unicode' and the russian and chinese filenames are shown
ok

In PC2, if I mount the shared directory with the same command, when I
execute 'ls unicode' I get the message "Segmentation fault" and nothing is
shown.

In PC2, if I mount the shared directory without the option "iocharset=utf8",
I can execute 'ls unicode', but now the russian/chinese filenames are not
(Continue reading)

Dean Davis | 11 Jul 2005 16:38

Slow Samba Share access to CIFS-mount - Win2k3 Share

Greetings CIFS-gods:

I'm not sure if this is the appropriate list, however, I'd like to know
if anyone has experienced unusually-slow connections from Windows
clients (Windows 200x/XP) to Samba shares that are based on CIFS mounts?

My configuration is as follows:
Fedora Core 3 box(x86):
It mounts a remote CIFS-exported share from a Windows 2003 server
The Samba (FC3) 3.0.10 server then shares the mounted directory to my
local Windows clients for seamless access.

Attempts to access the Samba share, which is based on the CIFS mount of
the Windows 2003 server, takes several minutes from Windows 200x/XP
clients to simply render the directory list. Oft-times the directory
list isn't returned; the request simply times out.

This issue was non-existent a few weeks ago when I mounted the exported
share using SMBFS, however, our share-provider has since upgraded the
box to Windows 2003, and we're stuck with the current configuration.

I've re-created the environment internally, on the LAN, using a Win2k3
server, and same result; consistent time-outs, leading me to believe
there's some bug in the mount.cifs implementation, or with Win2k3.

Any insight, tweaks, etc. would be greatly appreciated.

Regards,
--

-- 
Dean Davis,RHCE,MCSE,MCDBA,CCNA,Linux+
(Continue reading)

Dean Davis | 12 Jul 2005 00:26

Slow Samba Share access to CIFS-mount - Win2k3 Share

Greetings CIFS-gods:

I'm not sure if this is the appropriate list, however, I'd like to know
if anyone has experienced unusually-slow connections from Windows
clients (Windows 200x/XP) to Samba shares that are based on CIFS mounts?

My configuration is as follows:
Fedora Core 3 box(x86):
It mounts a remote CIFS-exported share from a Windows 2003 server
The Samba (FC3) 3.0.10 server then shares the mounted directory to my
local Windows clients for seamless access.

Attempts to access the Samba share, which is based on the CIFS mount of
the Windows 2003 server, takes several minutes from Windows 200x/XP
clients to simply render the directory list. Oft-times the directory
list isn't returned; the request simply times out.

This issue was non-existent a few weeks ago when I mounted the exported
share using SMBFS, however, our share-provider has since upgraded the
box to Windows 2003, and we're stuck with the current configuration.

I've re-created the environment internally, on the LAN, using a Win2k3
server, and same result; consistent time-outs, leading me to believe
there's some bug in the mount.cifs implementation, or with Win2k3.

Any insight, tweaks, etc. would be greatly appreciated.

Regards,
--
Dean Davis,RHCE,MCSE,MCDBA,CCNA,Linux+
Sr. Network Engineer
MBG Telecom Software
P. 212.822.4429
F. 212.822.4499
W. www.mbg-inc.com
GPG/PGP: 1024D/A9C110B4


--
The information in this email (including any attachments) is confidential and may be legally privileged.
Access to this e-mail by anyone other than the intended addressee is unauthorized.
If you are not the intended recipient of this message, any review, disclosure, copying, distribution,
retention, or any action taken or omitted to be taken in reliance on it (including any attachments)
is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward
a copy of this message to the sender and delete the message, all attachments, and any copies thereof
from your system and destroy any printout thereof.
This message has been scanned for viruses and
dangerous content and is believed to be clean.
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client <at> lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client
Dean Davis | 12 Jul 2005 19:19

Re: Slow Samba Share access to CIFS-mount - Win2k3Share

I seemed to have circumvented the issue by installing FC4. Apparently,
the Samba-build in FC4, plays nicer with Windows 2003 shares.

Now, I can mount using CIFS, Windows 2003 shares, into the Linux file
system, and re-export those shares using Samba, and the result from the
client-end (Windows 200x/XP/etc.) is significantly faster.

Many Regards,

On Mon, 2005-07-11 at 18:26 -0400, Dean Davis wrote:
> Greetings CIFS-gods:
> 
> I'm not sure if this is the appropriate list, however, I'd like to
> know
> if anyone has experienced unusually-slow connections from Windows
> clients (Windows 200x/XP) to Samba shares that are based on CIFS
> mounts?
> 
> My configuration is as follows:
> Fedora Core 3 box(x86):
> It mounts a remote CIFS-exported share from a Windows 2003 server
> The Samba (FC3) 3.0.10 server then shares the mounted directory to my
> local Windows clients for seamless access.
> 
> Attempts to access the Samba share, which is based on the CIFS mount
> of
> the Windows 2003 server, takes several minutes from Windows 200x/XP
> clients to simply render the directory list. Oft-times the directory
> list isn't returned; the request simply times out.
> 
> This issue was non-existent a few weeks ago when I mounted the
> exported
> share using SMBFS, however, our share-provider has since upgraded the
> box to Windows 2003, and we're stuck with the current configuration.
> 
> I've re-created the environment internally, on the LAN, using a Win2k3
> server, and same result; consistent time-outs, leading me to believe
> there's some bug in the mount.cifs implementation, or with Win2k3.
> 
> Any insight, tweaks, etc. would be greatly appreciated.
> 
> Regards,
> --
> Dean Davis,RHCE,MCSE,MCDBA,CCNA,Linux+
> Sr. Network Engineer
> MBG Telecom Software
> P. 212.822.4429
> F. 212.822.4499
> W. www.mbg-inc.com
> GPG/PGP: 1024D/A9C110B4
> 
> 
> 
> -- 
> The information in this email (including any attachments) is
> confidential and may be legally privileged. 
> Access to this e-mail by anyone other than the intended addressee is
> unauthorized. 
> If you are not the intended recipient of this message, any review,
> disclosure, copying, distribution, 
> retention, or any action taken or omitted to be taken in reliance on
> it (including any attachments) 
> is prohibited and may be unlawful. If you are not the intended
> recipient, please reply to or forward 
> a copy of this message to the sender and delete the message, all
> attachments, and any copies thereof 
> from your system and destroy any printout thereof. 
> This message has been scanned for viruses and 
> dangerous content and is believed to be clean. 
> plain text document attachment (ATT00013.txt), "ATT00013.txt"
> _______________________________________________
> linux-cifs-client mailing list
> linux-cifs-client <at> lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux-cifs-client
-- 
Dean Davis,RHCE,MCSE,MCDBA,CCNA,Linux+
Sr. Network Engineer
MBG Telecom Software
P. 212.822.4429
F. 212.822.4499
W. www.mbg-inc.com
GPG/PGP: 1024D/A9C110B4

--

-- 
The information in this email (including any attachments) is confidential and may be legally privileged.
Access to this e-mail by anyone other than the intended addressee is unauthorized. 

If you are not the intended recipient of this message, any review, disclosure, copying, distribution, 
retention, or any action taken or omitted to be taken in reliance on it (including any attachments) is 
prohibited and may be unlawful. 

If you are not the intended recipient, please reply to or forward a copy of this message to the sender and 
delete the message, all attachments, and any copies thereof from your system and destroy any printout thereof.

This message has been scanned for viruses and
dangerous content and is believed to be clean.
Steven French | 12 Jul 2005 23:32
Picon
Favicon

Re: How to stop cifs from printing passwords to the console?

This is puzzling since the mount.cifs does not display the actual parms passed internally to mount unless you mount with "--verbose" (or equivalently -v) mount option.

The cifs kernel code does not print the password in any case that I see to dmesg. I also did some experiments to verity this with old mount.cifs (version 1.3) and cifs.ko

What is the format of the message being displayed - it would be helpful if I could tell if it were the kernel or mount.cifs userspace code printing this.

Which version of cifs.ko and mount.cifs?


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
a.nielsen <at> research.uq.edu.au


          a.nielsen <at> research.uq.edu.au
          Sent by: linux-cifs-client-bounces+sfrench=us.ibm.com <at> lists.samba.org

          07/05/2005 09:20 PM


To

linux-cifs-client <at> lists.samba.org

cc


Subject

[linux-cifs-client] How to stop cifs from printing passwords to the console?

Hi,

I've just realised that although my CIFS passwords are stored in a
relatively secure credentials file, when the CIFS filesystems are mounted
during boot the full list of mount options is printed on the screen, which
includes usernames and passwords extracted from the credentials file.  This
means anyone who happens to be watching the machine during boot can see the
passwords.

Is there some way to prevent this from happening?  I don't recall compiling
extra debug output into the module.

Thanks,
Adam.
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client <at> lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client <at> lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client
Steven French | 20 Jul 2005 18:47
Picon
Favicon

Re: Slow Samba Share access to CIFS-mount - Win2k3 Share

Your post did not included enough information to be conclusive about the cause of the performance change after update of the server side to newer Windows server version, but there are a couple things that could be done to isolate it. I like to use more granular performance tools (iozone e.g., or the connectathon "nfs" tests run in timing "-t" mode) to compare before and after - and then compare with the network traces to see whether any particular type of request is slower after the change.

As a long shot (in the dark) .... A new performance consideration which I had not noticed before is TCP ack timeouts - depending on the size of the tcp window and various issues relating to TCP's "nagle" algorithm, TCP acks can be delayed to allow acks to be sent with subsequent requests or responses. This can be a disaster for performance of one process on one client talking to one server over very high speed links since it results in much dead time on the wire in which neither end is doing anything. Tuning around this (e.g. changing the sizes of the request buffer via insmod or on the server side) is a possibility and in any case is easy enough to do that it is worth trying. I am looking at how to disable the nagle algorithm code on the socket on the client as well. This may have nothing to do with it, but I stumbled across it when I saw that a performance improvement I had made in some cases made things an order of magnitude slower when larger responses were sent.


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client <at> lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client
Naidu Bollineni | 20 Jul 2005 22:27

RE: Find_First with InfoLevel 0x104(260) doesn't

I am wondering if an attempt to use Infolevel 0x104 on FirstFirst is showing correct output.

 

For me it did not because the structure FILE_BOTH_DIRECTORY_INFO has member Shortname declared __u8 inctead of __u16.

 

Changing it to __u16 is showing correct result, and ethereal trace does confirm there are 24 bytes before the real Unicode FileName of the entry.

 

Naidu Bollineni

Senior Member Technical Staff

Kazeon Systems

naidu <at> kazeon.com

www.kazeon.com

From: linux-cifs-client-bounces+naidu=kazeon.com <at> lists.samba.org [mailto:linux-cifs-client-bounces+naidu=kazeon.com <at> lists.samba.org] On Behalf Of Steven French
Sent: Wednesday, July 20, 2005 9:47 AM
To: dean.davis <at> mbg-inc.com
Cc: linux-cifs-client <at> lists.samba.org
Subject: Re: [linux-cifs-client] Slow Samba Share access to CIFS-mount - Win2k3Share

 

Your post did not included enough information to be conclusive about the cause of the performance change after update of the server side to newer Windows server version, but there are a couple things that could be done to isolate it. I like to use more granular performance tools (iozone e.g., or the connectathon "nfs" tests run in timing "-t" mode) to compare before and after - and then compare with the network traces to see whether any particular type of request is slower after the change.

As a long shot (in the dark) .... A new performance consideration which I had not noticed before is TCP ack timeouts - depending on the size of the tcp window and various issues relating to TCP's "nagle" algorithm, TCP acks can be delayed to allow acks to be sent with subsequent requests or responses. This can be a disaster for performance of one process on one client talking to one server over very high speed links since it results in much dead time on the wire in which neither end is doing anything. Tuning around this (e.g. changing the sizes of the request buffer via insmod or on the server side) is a possibility and in any case is easy enough to do that it is worth trying. I am looking at how to disable the nagle algorithm code on the socket on the client as well. This may have nothing to do with it, but I stumbled across it when I saw that a performance improvement I had made in some cases made things an order of magnitude slower when larger responses were sent.


Steve French
Senior Software Engineer
LinuxTechnologyCenter - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client <at> lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client
Steven French | 20 Jul 2005 22:55
Picon
Favicon

RE: Find_First with InfoLevel 0x104(260) doesn't


> For me it did not because the structure FILE_BOTH_DIRECTORY_INFO has member Shortname declared __u8 inctead of __u16.

I don't see the readdir code using that level (0x104), just SMB_FIND_FILE_DIRECTORY_INFO (0x101) and SMB_FIND_FILE_FULL_DIRECTORY_INFO (0x102) as well as the Unix extensions find level, so shortname should not be an issue there (it is not returned by 101 and 102 and the cifs client does not need it). If shortname length were not calculated correctly and level 104 were ever issued, readdir should fail horribly since filename would be wrong.


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com

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

Gmane