[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Unidentified subject!
From:       Steve Langasek <vorlon () dodds ! net>
Date:       2000-03-27 23:13:28
[Download RAW message or body]

On Fri, 24 Mar 2000, Oleg Noskov wrote:

> here at Corel we already have pretty much the same functionality you're
> discussing here already developed and shipping since Corel Linux 1.0.

> Here's what we do in brief:

> - we have a constantly running server process (called netserv) which does
>     a) UNC name resolution and handing
>     b) Credentials (username/domain/password) caching
>     c) Autmounting of shares
> - we have a shared library (libmwn) which is acting as a wrapper for
> Linux file I/O. We have our wrappers for open/fopen/access/stat/unlink
> etc. library functions and system calls. Internally, libmwn looks if a
> file name is a UNC filename and in such case it issues a "netmap" call
> to the netserv process. Netserv mounts the corresponding share in the
> temporary location if necessary (or reuses earlier mounted share if UID
> of the caller is the same) and returns temporary local path to the
> libmwn. Libmwn passes that name to the native function/system call and
> returns to the calling program. When mounting, netserv uses its
> credentials cache to find out which set of credentials to use.  If
> necessary, user will be prompted for new set of credentials (works OK
> for us). Netserv monitors successful network access attempts and updates
> its cache.

Are there also checks in place to ensure that a user is not granted access
to credentials which were previously provided by another user?

If, as you say, the shares are mounted as part of the virtual filesystem,
I'm still concerned that this will allow unauthorized users
(local administrators included) to access these network resources.

Also, if you have constructed wrappers for filesystem I/O, isn't using
smbmount somewhat superfluous?  It seems to me that it would be easier
(and more portable) to use the smbwrapper library in this scenario: the
only argument against using smbwrapper has been that it doesn't work with
glibc 2.1, but this doesn't seem to be a problem for you.

Regards,
Steve Langasek
postmodern programmer

[prev in list] [next in list] [prev in thread] [next in thread]