From: Steve French <smfrench@austin.rr.com>
To: eric2.valette@francetelecom.com
Cc: linux-kernel@vger.kernel.org, linux-cifs-client@lists.samba.org
Subject: CIFS emulated mode bits
Date: Tue, 22 Nov 2005 10:30:40 -0600 [thread overview]
Message-ID: <438347B0.9020602@austin.rr.com> (raw)
In-Reply-To: <438323AC.2090102@francetelecom.com>
VALETTE Eric RD-MAPS-REN wrote:
>Steve French wrote:
>
>
>>VALETTE Eric RD-MAPS-REN wrote:
>>
>>
>>
>>>Steve French wrote:
>>>
>>>
>>let me know if your cat example works when mounted
>>with the relatively new "noperm" mount option on the client. At least
>>then we will know whether we are looking at a problem with access
>>control on the server (ntfs acls) or client (unix mode bits and the
>>.permission entry point)
>>
>>
>
>Works with the "noperm" mount option.
>
>--eric
>
>
>
OK - That is good, should be relatively easy to debug from here.
To explain what is going on, here is some obvious background. Windows
uses a rich ACL model locally and over the network via CIFS (other
protocols such as NFSv4 now do something similar) and Windows of course
does not have really have or need Unix mode bits ... and the server
(unlike Samba and those that implement the standard SNIA CIFS Unix
extensions) does not return emulated mode bits (although it does locally
in Windows "services for Unix" and of course also cygwin does something
similar) ... so the cifs client has to approximate mode bits. If the
client makes an incorrect approximation you can get access denied on a
client side permission check. Of course some would argue that for
clients that are running as single user desktop clients the client does
not need to do perm checks (the server does ACL checks) so just turn off
the client permission checks - that is why the "noperm" option is
available on the cifs client.
So the choices today are:
1) Turn off mode bit checking (on the client) on a particular cifs mount
(noperm mount option)
or
2) pass in a default mode and uid or gid on the cifs mount that matches
what you want (otherwise cifs will use the uid of the mounter, and a
default mode). Although cifs caches the mode bits in the inode if they
are modified by an app on the client e.g. via chmod (while the inode
stays in memory on the client) - for querying (lookups/stat) on existing
files cifs can only use the +R dos attribute to distinguish when to
return something other than 0777 (or the default).
or
3) turn on the "sfu" mount option on the client and let cifs make the
(more expensive) queries to the server for mode information the same way
that "services for unix" would. This does not work for all mode bits
yet, as it requires additional CIFS ACL support to be coded, but it does
now work for the 3 bits above 0777 (as of just after 2.6.15-rc2).
Following the suggestions of Martin Koeppe and others there may be a
need to allow a "cygwin" mount option as well.
next prev parent reply other threads:[~2005-11-22 16:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-21 16:04 CIFS improvements/wider testing needed Steve French
2005-11-21 17:26 ` VALETTE Eric RD-MAPS-REN
2005-11-21 21:28 ` Steve French
2005-11-22 9:19 ` VALETTE Eric RD-MAPS-REN
[not found] ` <43834052.4090509@austin.rr.com>
2005-11-22 16:47 ` VALETTE Eric RD-MAPS-REN
2005-11-21 21:31 ` Steve French
2005-11-22 10:36 ` VALETTE Eric RD-MAPS-REN
2005-11-22 13:57 ` VALETTE Eric RD-MAPS-REN
2005-11-22 16:30 ` Steve French [this message]
2005-11-22 17:17 ` CIFS emulated mode bits VALETTE Eric RD-MAPS-REN
[not found] ` <43834994.10006@austin.rr.com>
2005-11-22 17:24 ` CIFS improvements/wider testing needed VALETTE Eric RD-MAPS-REN
-- strict thread matches above, loose matches on Subject: below --
2005-11-22 16:40 CIFS emulated mode bits Steve French
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=438347B0.9020602@austin.rr.com \
--to=smfrench@austin.rr.com \
--cc=eric2.valette@francetelecom.com \
--cc=linux-cifs-client@lists.samba.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox