From: Mike Petersen (mgpeter_at_pcc-services.com)
Date: Wed Jul 05 2006 - 15:14:00 CEST
From: Mike Petersen <mgpeter@pcc-services.com> Date: Wed, 05 Jul 2006 08:14:00 -0500 Message-Id: <1152105240.3611.16.camel@inspiron2650.private.lan> Subject: Re: [suse-sles-e] macs and CIFS/SAMBA
Peter,
The problem is that SMB/CIFS is not like NFS. When a Samba Server (or
any other client) "mounts" a SMB/CIFS share, you have to provide a
username/password in order to gain access to that share. For instance if
you have a Windows Share called "Test" on a Windows machine called
"Win2K", when you "mount" the //win2k/test share on the SLES machine you
need to provide "credentials" - a username and password (lets say
linuser1) to gain access to that share. If you turn around and "share"
that data from the SLES machine, no matter what username a client
connects to the SLES machine as (such as macuser1), the SLES machine
will continue to do all read and writes to //win2k/test as the username
linuser1 regardless whether or not macuser1 has original access to the \
\win2k\test share. This is where the security risk is involved.
NFS does not have this "issue" so it is very well suited to be mounted
across multiple servers and workstation machines.
But again if you don't need too much security for the original Windows
share it would probably work fine.
Mike Petersen
mgpeter@pcc-services.com
On Tue, 2006-07-04 at 16:47 -0500, Peter Van Lone wrote:
> On 6/27/06, Mike Petersen <mgpeter@pcc-services.com> wrote:
> > Being a member server would simply allow SLES to provide shares that can
> > be accessed by the anyone in the User Database from the Windows Server -
> > if the data resides on a Windows Server in the first place, SLES still
> > access that data through a Username "token" when it mounts that data.
> > This would be a big security risk, especially if the company cares that
> > much about it's data.
>
> I've been out of town, had to let this ball drop for awhile ..
>
> can you give me just a bit more detail about what you mean by this?
> How is this a security threat? Is it that the username "token" is in
> clear text? Does it somehow change the security rights that each mac
> user would recieve when they open a document?
>
> Generally I don't think there is much need for security ... this is
> massive document data storage for a print/production house and the mac
> users need to get the data for graphic work primarily. From what I
> understand ... there is one big share and many many directories/
> sub-directories and many many files. The issue is the very slow time
> for macs to get a directory list. This does not happen with windows
> clients.
>
> A peer has passed me a knowledge article link, that I do not this
> moment have access to, that details the "known problem" that they
> believe is occuring. If it is interesting to you, I would be happy to
> attach the url later.
>
> The thing I'm trying to figure out is whether it makes any sense to do
> this ... Novell has a cool solutions article about using SLES as a NAS
> front-end for remote NFS storage. If it makes sense to do this with
> the CIFS/SAMBA remote storage, it might be a solution to this problem.
>
> If it does not makes sense to do it, it would be helpful have some
> specifics about why, so that I can share it with the team and
> discourage even attempting to pilot the solution.
>
> > Maybe you should be looking to Microsoft or the SAN vendor to provide a
> > NFS Server for the Unix/MacOS clients.
>
> again, if I can understand why the proposal won't work, then I would
> of course suggest this.
>
> Thanx
>
> Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: suse-sles-e-unsubscribe@suse.com
For additional commands, e-mail: suse-sles-e-help@suse.com
This archive was generated by hypermail 2.1.7 : Wed Jul 05 2006 - 15:14:17 CEST