1.7.1-1 noacl on samba share has incorrect directory write bit

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

1.7.1-1 noacl on samba share has incorrect directory write bit

Raman Gupta
I have an smbfs mount (served by samba 3.4.2) in noacl mode on cygwin
1.7.1-1:

//smserver/smshare on /mnt/shar type smbfs (binary,notexec,noacl,user)

Here is the directory as seen on the unix server directly:

root@smserver foo]# ls -ald bar
dr-xr-sr-x.  2 root  agroup  4096 2007-04-21 23:23 bar

As you can see, the directory bar is not writable.

However, here is what cygwin in noacl mode sees:

Raman Gupta@client /mnt/shar/foo
$ ls -ald bar
drwxr-xr-x 1 Raman Gupta None 0 2007-04-21 23:23 bar

The mode shown is 755 rather than 555, and indeed cygwin does not have
write access to this directory:

Raman Gupta@client /mnt/shar/foo/bar
$ touch baz
touch: cannot touch `baz': Permission denied

Shouldn't cygwin therefore read the permissions as 555?

In acl mode, cygwin does correctly show these directory permissions as
555.

Note that read-only *files* are correctly displayed by cygwin/noacl as
444.

Thanks,
Raman

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: 1.7.1-1 noacl on samba share has incorrect directory write bit

Larry Hall (Cygwin)
On 01/06/2010 09:22 PM, Raman Gupta wrote:

> I have an smbfs mount (served by samba 3.4.2) in noacl mode on cygwin
> 1.7.1-1:
>
> //smserver/smshare on /mnt/shar type smbfs (binary,notexec,noacl,user)
>
> Here is the directory as seen on the unix server directly:
>
> root@smserver foo]# ls -ald bar
> dr-xr-sr-x. 2 root agroup 4096 2007-04-21 23:23 bar
>
> As you can see, the directory bar is not writable.
>
> However, here is what cygwin in noacl mode sees:
>
> Raman Gupta@client /mnt/shar/foo
> $ ls -ald bar
> drwxr-xr-x 1 Raman Gupta None 0 2007-04-21 23:23 bar
>
> The mode shown is 755 rather than 555, and indeed cygwin does not have
> write access to this directory:
>
> Raman Gupta@client /mnt/shar/foo/bar
> $ touch baz
> touch: cannot touch `baz': Permission denied
>
> Shouldn't cygwin therefore read the permissions as 555?
>
> In acl mode, cygwin does correctly show these directory permissions as 555.
>
> Note that read-only *files* are correctly displayed by cygwin/noacl as 444.

Well, you've told Cygwin that it shouldn't consult the file system for
permissions.
So you see is what Cygwin defaults to in these situations.  If you ask Cygwin
to tell you the permissions on something in a file system where you also told
it not to check the permissions, you don't expect to see the actual correct
permissions, do you?

--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: 1.7.1-1 noacl on samba share has incorrect directory write bit

Raman Gupta
On 01/06/2010 10:01 PM, Larry Hall (Cygwin) wrote:

> On 01/06/2010 09:22 PM, Raman Gupta wrote:
>> I have an smbfs mount (served by samba 3.4.2) in noacl mode on cygwin
>> 1.7.1-1:
>>
>> //smserver/smshare on /mnt/shar type smbfs (binary,notexec,noacl,user)
>>
>> Here is the directory as seen on the unix server directly:
>>
>> root@smserver foo]# ls -ald bar
>> dr-xr-sr-x. 2 root agroup 4096 2007-04-21 23:23 bar
>>
>> As you can see, the directory bar is not writable.
>>
>> However, here is what cygwin in noacl mode sees:
>>
>> Raman Gupta@client /mnt/shar/foo
>> $ ls -ald bar
>> drwxr-xr-x 1 Raman Gupta None 0 2007-04-21 23:23 bar
>>
>> The mode shown is 755 rather than 555, and indeed cygwin does not have
>> write access to this directory:
>>
>> Raman Gupta@client /mnt/shar/foo/bar
>> $ touch baz
>> touch: cannot touch `baz': Permission denied
>>
>> Shouldn't cygwin therefore read the permissions as 555?
>>
>> In acl mode, cygwin does correctly show these directory permissions as
>> 555.
>>
>> Note that read-only *files* are correctly displayed by cygwin/noacl as
>> 444.
>
> Well, you've told Cygwin that it shouldn't consult the file system
> for permissions. So you see is what Cygwin defaults to in these
> situations. If you ask Cygwin to tell you the permissions on
> something in a file system where you also told it not to check the
> permissions, you don't expect to see  the actual correct
 > permissions, do you?

Well... yes -- at least in this case. As per the documentation
(http://www.cygwin.com/cygwin-ug-net/using.html#mount-table):

"Cygwin ignores filesystem ACLs and only fakes a subset of permission
bits based on the DOS readonly attribute"

On the server:

root@smserver foo]# ls -ald bar baz
dr-xr-sr-x. 2 root agroup 4096 2007-04-21 23:23 bar
drwxrwsr-x. 2 root agroup 4096 2007-04-21 23:23 baz

Since the default behavior of Samba is to map the DOS read-only flag
as per the write bits
(http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#MAPREADONLY),
the write bits carry over to the DOS readonly attribute on the share.
This can be verified via the DOS attrib command on the client:

Raman Gupta@client /mnt/shar/foo
$ attrib bar
      R     \\smserver\smshare\foo\bar

Raman Gupta@client /mnt/shar/foo
$ attrib baz
            \\smserver\smshare\foo\baz

and yet, Cygwin reports owner write bit set in both cases:

Raman Gupta@client /mnt/shar/foo
$ ls -ald bar baz
drwxr-xr-x 1 Raman Gupta None 0 2007-04-21 23:23 bar
drwxr-xr-x 1 Raman Gupta None 0 2007-04-21 23:23 baz

Therefore, it appears that cygwin is following its own documentation
for files but not for directories.

Cheers,
Raman

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: 1.7.1-1 noacl on samba share has incorrect directory write bit

Corinna Vinschen-2
On Jan  7 00:39, Raman Gupta wrote:

> Well... yes -- at least in this case. As per the documentation
> (http://www.cygwin.com/cygwin-ug-net/using.html#mount-table):
>
> "Cygwin ignores filesystem ACLs and only fakes a subset of
> permission bits based on the DOS readonly attribute"
>
> On the server:
>
> root@smserver foo]# ls -ald bar baz
> dr-xr-sr-x. 2 root agroup 4096 2007-04-21 23:23 bar
> drwxrwsr-x. 2 root agroup 4096 2007-04-21 23:23 baz
>
> Since the default behavior of Samba is to map the DOS read-only flag
> as per the write bits (http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#MAPREADONLY),
> the write bits carry over to the DOS readonly attribute on the
> share. This can be verified via the DOS attrib command on the
> client:
>
> Raman Gupta@client /mnt/shar/foo
> $ attrib bar
>      R     \\smserver\smshare\foo\bar
>
> Raman Gupta@client /mnt/shar/foo
> $ attrib baz
>            \\smserver\smshare\foo\baz
>
> and yet, Cygwin reports owner write bit set in both cases:
>
> Raman Gupta@client /mnt/shar/foo
> $ ls -ald bar baz
> drwxr-xr-x 1 Raman Gupta None 0 2007-04-21 23:23 bar
> drwxr-xr-x 1 Raman Gupta None 0 2007-04-21 23:23 baz
>
> Therefore, it appears that cygwin is following its own documentation
> for files but not for directories.

No, it's a bit more tricky.  FAT filesystems, which are the role model
for noacl filesystems don't know something like a R/O directory.  The
DOS R/O bit on a directory does NOT mean the directory is R/O.  Rather,
it only means that the folder is some sort of special folder.  For some
better description, see http://support.microsoft.com/kb/326549.

Therefore the fault is not on Cygwin's side, but on Samba's side to use
the DOS R/O bit for something different than Windows uses it on
directories.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: 1.7.1-1 noacl on samba share has incorrect directory write bit

Raman Gupta
On 01/07/2010 01:02 PM, Corinna Vinschen wrote:
> On Jan  7 00:39, Raman Gupta wrote:
>> Well... yes -- at least in this case. As per the documentation
>> (http://www.cygwin.com/cygwin-ug-net/using.html#mount-table):
>>
>> "Cygwin ignores filesystem ACLs and only fakes a subset of
>> permission bits based on the DOS readonly attribute"
 >
> No, it's a bit more tricky.  FAT filesystems, which are the role model
> for noacl filesystems don't know something like a R/O directory.  The
> DOS R/O bit on a directory does NOT mean the directory is R/O.  Rather,
> it only means that the folder is some sort of special folder.  For some
> better description, see http://support.microsoft.com/kb/326549.

Wow, isn't that just like Microsoft to reuse an existing read-only bit
for something that is completely different semantically!

In any case, note that the KB article says that attrib *can* be used
to see and modify the value -- as I demonstrated in my previous email.

> Therefore the fault is not on Cygwin's side, but on Samba's side to use
> the DOS R/O bit for something different than Windows uses it on
> directories.

Understood. However, while Samba's use of the read-only bit on
directories does differ somewhat from what Windows Explorer expects to
use that bit for, it is a valid field and it does provide useful
information to the client in the case of noacl Samba mounts.

Therefore, what would you think about configuring this via a mount
option? For example, a per-mount setting called dro/nodro (directory
read-only / no directory read-only) that tells cygwin whether it
should look at the read-only bit or not when calculating the
permissions of directories with noacl? The option would be ignored in
acl mode.

This type of setting would be really useful for noacl mode with samba
mounts, as it would allow the actual write status of the directory to
be shown clearly by cygwin. I haven't checked the cygwin internals,
but might it also allow a slight performance improvement since when
one attempts to, say, "touch foo" inside such a directory, cygwin
could check if this bit was set before actually attempting to write
the file and failing (assuming "dro" is on)?

Cheers,
Raman

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: 1.7.1-1 noacl on samba share has incorrect directory write bit

Corinna Vinschen-2
On Jan  7 13:42, Raman Gupta wrote:

> On 01/07/2010 01:02 PM, Corinna Vinschen wrote:
> >On Jan  7 00:39, Raman Gupta wrote:
> >>"Cygwin ignores filesystem ACLs and only fakes a subset of
> >>permission bits based on the DOS readonly attribute"
> >
> >No, it's a bit more tricky.  FAT filesystems, which are the role model
> >for noacl filesystems don't know something like a R/O directory.  The
> >DOS R/O bit on a directory does NOT mean the directory is R/O.  Rather,
> >it only means that the folder is some sort of special folder.  For some
> >better description, see http://support.microsoft.com/kb/326549.
>
> Wow, isn't that just like Microsoft to reuse an existing read-only
> bit for something that is completely different semantically!
>
> In any case, note that the KB article says that attrib *can* be used
> to see and modify the value -- as I demonstrated in my previous
> email.

Sure.  That has nothing to do with what I'm talking about.  While you
can set and reset the R/O bit on a dir, it doesn't have the *meaning* of
the directory being R/O.  If Cygwin reports such a directory as being
read-only from the POSIX perspective, certain functions would have
strange ideas and return EACCES, for instance.

> >Therefore the fault is not on Cygwin's side, but on Samba's side to use
> >the DOS R/O bit for something different than Windows uses it on
> >directories.
>
> Understood. However, while Samba's use of the read-only bit on
> directories does differ somewhat from what Windows Explorer expects
> to use that bit for, it is a valid field and it does provide useful
> information to the client in the case of noacl Samba mounts.
>
> Therefore, what would you think about configuring this via a mount
> option? For example, a per-mount setting called dro/nodro (directory

That's not the right thing to do, IMHO.  That's what the default "acl"
mount mode is for.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: 1.7.1-1 noacl on samba share has incorrect directory write bit

Raman Gupta
On 01/07/2010 02:50 PM, Corinna Vinschen wrote:

> On Jan  7 13:42, Raman Gupta wrote:
>> On 01/07/2010 01:02 PM, Corinna Vinschen wrote:
>>> On Jan  7 00:39, Raman Gupta wrote:
>>>> "Cygwin ignores filesystem ACLs and only fakes a subset of
>>>> permission bits based on the DOS readonly attribute"
>>>
>>> No, it's a bit more tricky.  FAT filesystems, which are the role model
>>> for noacl filesystems don't know something like a R/O directory.  The
>>> DOS R/O bit on a directory does NOT mean the directory is R/O.  Rather,
>>> it only means that the folder is some sort of special folder.  For some
>>> better description, see http://support.microsoft.com/kb/326549.
>>
>> Wow, isn't that just like Microsoft to reuse an existing read-only
>> bit for something that is completely different semantically!
>>
>> In any case, note that the KB article says that attrib *can* be used
>> to see and modify the value -- as I demonstrated in my previous
>> email.
>
> Sure.  That has nothing to do with what I'm talking about.  While you
> can set and reset the R/O bit on a dir, it doesn't have the *meaning* of
> the directory being R/O.  If Cygwin reports such a directory as being
> read-only from the POSIX perspective, certain functions would have
> strange ideas and return EACCES, for instance.

In the case I am speaking of (a Samba share using the default
settings), the functions *should* return EACCES, since on the
server-side the directory is indeed non-writable.

>>> Therefore the fault is not on Cygwin's side, but on Samba's side to use
>>> the DOS R/O bit for something different than Windows uses it on
>>> directories.
>>
>> Understood. However, while Samba's use of the read-only bit on
>> directories does differ somewhat from what Windows Explorer expects
>> to use that bit for, it is a valid field and it does provide useful
>> information to the client in the case of noacl Samba mounts.
>>
>> Therefore, what would you think about configuring this via a mount
>> option? For example, a per-mount setting called dro/nodro (directory
>
> That's not the right thing to do, IMHO.  That's what the default "acl"
> mount mode is for.

Unfortunately, acl mode is unusable when in a non-domain environment.

Cheers,
Raman

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: 1.7.1-1 noacl on samba share has incorrect directory write bit

Corinna Vinschen-2
On Jan  7 15:00, Raman Gupta wrote:

> On 01/07/2010 02:50 PM, Corinna Vinschen wrote:
> >On Jan  7 13:42, Raman Gupta wrote:
> >>In any case, note that the KB article says that attrib *can* be used
> >>to see and modify the value -- as I demonstrated in my previous
> >>email.
> >
> >Sure.  That has nothing to do with what I'm talking about.  While you
> >can set and reset the R/O bit on a dir, it doesn't have the *meaning* of
> >the directory being R/O.  If Cygwin reports such a directory as being
> >read-only from the POSIX perspective, certain functions would have
> >strange ideas and return EACCES, for instance.
>
> In the case I am speaking of (a Samba share using the default
> settings), the functions *should* return EACCES, since on the
> server-side the directory is indeed non-writable.

I'm talking about the other case.  The DOS R/O flag has nothing to do
with writability of a directory in the first place.  If we treat a
directory as non-writable just because the DOS R/O flag is set, we're
making a mistake with consequences.  The consequences in the opposite
case are much less problematic.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: 1.7.1-1 noacl on samba share has incorrect directory write bit

Raman Gupta
On 01/07/2010 03:09 PM, Corinna Vinschen wrote:

> On Jan  7 15:00, Raman Gupta wrote:
>> On 01/07/2010 02:50 PM, Corinna Vinschen wrote:
>>> On Jan  7 13:42, Raman Gupta wrote:
>>>> In any case, note that the KB article says that attrib *can* be used
>>>> to see and modify the value -- as I demonstrated in my previous
>>>> email.
>>>
>>> Sure.  That has nothing to do with what I'm talking about.  While you
>>> can set and reset the R/O bit on a dir, it doesn't have the *meaning* of
>>> the directory being R/O.  If Cygwin reports such a directory as being
>>> read-only from the POSIX perspective, certain functions would have
>>> strange ideas and return EACCES, for instance.
>>
>> In the case I am speaking of (a Samba share using the default
>> settings), the functions *should* return EACCES, since on the
>> server-side the directory is indeed non-writable.
>
> I'm talking about the other case.  The DOS R/O flag has nothing to do
> with writability of a directory in the first place.  If we treat a
> directory as non-writable just because the DOS R/O flag is set, we're
> making a mistake with consequences.  The consequences in the opposite
> case are much less problematic.

Right -- which is why I suggested gating this using a "dro/nodro"
attribute so that it could be turned on by users of noacl samba mounts
where it would be correct to turn it on -- I suspect noacl samba
mounts are widely used and would benefit greatly from this as EACCES
would be correctly returned in many situations in which it currently
isn't.

Since nodro (i.e. current behavior) would remain the default, there
should be no negative consequences.

Cheers,
Raman

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: 1.7.1-1 noacl on samba share has incorrect directory write bit

Corinna Vinschen-2
On Jan  7 15:25, Raman Gupta wrote:

> On 01/07/2010 03:09 PM, Corinna Vinschen wrote:
> >I'm talking about the other case.  The DOS R/O flag has nothing to do
> >with writability of a directory in the first place.  If we treat a
> >directory as non-writable just because the DOS R/O flag is set, we're
> >making a mistake with consequences.  The consequences in the opposite
> >case are much less problematic.
>
> Right -- which is why I suggested gating this using a "dro/nodro"
> attribute so that it could be turned on by users of noacl samba
> mounts where it would be correct to turn it on -- I suspect noacl
> samba mounts are widely used and would benefit greatly from this as
> EACCES would be correctly returned in many situations in which it
> currently isn't.

Show me an example.  The actual permissions are so that your actions
already return EACCES.  I don't see lots of a win which would rectify
another mount option.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: 1.7.1-1 noacl on samba share has incorrect directory write bit

Raman Gupta
On 01/08/2010 05:32 AM, Corinna Vinschen wrote:

> On Jan  7 15:25, Raman Gupta wrote:
>> On 01/07/2010 03:09 PM, Corinna Vinschen wrote:
>>> I'm talking about the other case.  The DOS R/O flag has nothing to do
>>> with writability of a directory in the first place.  If we treat a
>>> directory as non-writable just because the DOS R/O flag is set, we're
>>> making a mistake with consequences.  The consequences in the opposite
>>> case are much less problematic.
>>
>> Right -- which is why I suggested gating this using a "dro/nodro"
>> attribute so that it could be turned on by users of noacl samba
>> mounts where it would be correct to turn it on -- I suspect noacl
>> samba mounts are widely used and would benefit greatly from this as
>> EACCES would be correctly returned in many situations in which it
>> currently isn't.
>
> Show me an example.  The actual permissions are so that your actions
> already return EACCES.  I don't see lots of a win which would rectify
> another mount option.

Here is a simple foundational example -- assume "foo" is a
non-writable directory on an smbfs share mounted with noacl, using the
default samba share options:

$ if [[ -w foo ]]; then echo "writable"; else echo "not writable"; fi;
writable

which is of course incorrect as the directory is not actually writable:

$ touch foo/bar
touch: cannot touch `foo/bar': Permission denied

Another example is copying (with perms) from a noacl mount to an acl
mount. The permissions of directories copied to the acl mount should
be non-writable (and would be with the dro option) but currently the
permissions on the acl mount are incorrectly set as writable:

Assume the following mounts:

//s/a on /mnt/acl type smbfs (binary,notexec,user)
//s/a on /mnt/noacl type smbfs (binary,notexec,noacl,user)
C:/cygwin on / type ntfs (binary,auto)

Share "a", again using the default samba options, contains a
non-writable directory called "foo":

Now run:

$ mkdir /tmp/from_acl; mkdir /tmp/from_noacl

$ unison -auto -batch /mnt/acl /tmp/from_acl
[...]

$ unison -auto -batch /mnt/noacl /tmp/from_noacl
[...]

$ ls -l /tmp/from_acl
total 0
dr-x------+ 1 Raman Gupta None 0 2010-01-08 11:36 foo

$ ls -l /tmp/from_noacl
total 0
drwx------+ 1 Raman Gupta None 0 2010-01-08 11:36 foo

With the dro option, the latter would correctly remove the write bit
on foo in /tmp/from_noacl.

Cheers,
Raman

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: 1.7.1-1 noacl on samba share has incorrect directory write bit

Larry Hall (Cygwin)
On 01/08/2010 11:50 AM, Raman Gupta wrote:
> With the dro option, the latter would correctly remove the write bit on
> foo in /tmp/from_noacl.

So perhaps you can explain why setting "acl" isn't the solution here?

--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: 1.7.1-1 noacl on samba share has incorrect directory write bit

Raman Gupta
On 01/08/2010 03:21 PM, Larry Hall (Cygwin) wrote:
> On 01/08/2010 11:50 AM, Raman Gupta wrote:
>> With the dro option, the latter would correctly remove the write bit on
>> foo in /tmp/from_noacl.
>
> So perhaps you can explain why setting "acl" isn't the solution here?

Unfortunately, acl mode is unusable in a non-domain environment as all
the files have ownership/permissions relative to the server user/group
rather than the client workstation user/group.

Reference this mailing list discussion back in 2000:

http://sources.redhat.com/ml/cygwin/2000-12/msg00546.html

It appears this discussion is actually what led Corinna to add the
smbntsec mount option. The issues are summarized well in this mail
from Charles Wilson:

http://sources.redhat.com/ml/cygwin/2000-12/msg00756.html

Cheers,
Raman

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: 1.7.1-1 noacl on samba share has incorrect directory write bit

Corinna Vinschen-2
On Jan  9 01:00, Raman Gupta wrote:

> On 01/08/2010 03:21 PM, Larry Hall (Cygwin) wrote:
> >On 01/08/2010 11:50 AM, Raman Gupta wrote:
> >>With the dro option, the latter would correctly remove the write bit on
> >>foo in /tmp/from_noacl.
> >
> >So perhaps you can explain why setting "acl" isn't the solution here?
>
> Unfortunately, acl mode is unusable in a non-domain environment as
> all the files have ownership/permissions relative to the server
> user/group rather than the client workstation user/group.
>
> Reference this mailing list discussion back in 2000:
>
> http://sources.redhat.com/ml/cygwin/2000-12/msg00546.html
>
> It appears this discussion is actually what led Corinna to add the
> smbntsec mount option. The issues are summarized well in this mail
> from Charles Wilson:
>
> http://sources.redhat.com/ml/cygwin/2000-12/msg00756.html

The problems are mostely fixed.  I'm using this setting for a long
while now.  The ownership is the one of the UNIX user and group,
but that doesn't change the fact that you can read and change the
permissions.  You can even fetch the user and groups from the Samba
server using mkpasswd and mkgroup.  Looks like this in my environment:

  $ mkpasswd -L calimero -S_ -U root,corinna
  Unix User_root:unused:10000:99999:,S-1-22-1-0::
  Unix User_corinna:unused:10500:99999:,S-1-22-1-500::

  $ mkgroup -L calimero -S_ -U root,users
  Unix Group_root:S-1-22-2-0:10000:
  Unix Group_users:S-1-22-2-100:10100:


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: 1.7.1-1 noacl on samba share has incorrect directory write bit

Raman Gupta
On 01/09/2010 05:06 AM, Corinna Vinschen wrote:

> On Jan  9 01:00, Raman Gupta wrote:
>> Reference this mailing list discussion back in 2000:
>>
>> http://sources.redhat.com/ml/cygwin/2000-12/msg00546.html
>>
>> It appears this discussion is actually what led Corinna to add the
>> smbntsec mount option. The issues are summarized well in this mail
>> from Charles Wilson:
>>
>> http://sources.redhat.com/ml/cygwin/2000-12/msg00756.html
>
> The problems are mostely fixed.  I'm using this setting for a long
> while now.  The ownership is the one of the UNIX user and group,
> but that doesn't change the fact that you can read and change the
> permissions.  You can even fetch the user and groups from the Samba
> server using mkpasswd and mkgroup.  Looks like this in my environment:
>
>    $ mkpasswd -L calimero -S_ -U root,corinna
>    Unix User_root:unused:10000:99999:,S-1-22-1-0::
>    Unix User_corinna:unused:10500:99999:,S-1-22-1-500::
>
>    $ mkgroup -L calimero -S_ -U root,users
>    Unix Group_root:S-1-22-2-0:10000:
>    Unix Group_users:S-1-22-2-100:10100:

I've tried this but I get, for example, permission denied when trying
to change permissions on files. Here is an example:

$ ls -l
-rw-r--r-- 1 Unix User_root  Unix Group_agroup 0 2010-01-09 09:54 bar
-rw-r--r-- 1 SERVER_raman    Unix Group_agroup 0 2010-01-09 09:50 foo

$ id
uid=1004(Raman Gupta) gid=513(None) groups=0(root),544(Administrators),545(Users),513(None)

$ chmod 444 foo
chmod: changing permissions of `foo': Permission denied

One thing I'm not certain about is why mkpasswd returns my username
twice, once with a "Unix User" prefix and once with "SERVER" prefix
-- I note your example does not do that:

$ mkpasswd -L server -S_ -U root,raman
Unix User_root:unused:10000:99999:,S-1-22-1-0::
Unix User_raman:unused:10500:99999:,S-1-22-1-500::
SERVER_raman:unused:11000:10513:Raman Gupta,U-SERVER\raman,S-1-5-21-903485053-2526882046-1379677160-1000://server/raman:/bin/bash

I also note that the file ownership is shown with the "SERVER"
prefix and not the "Unix User" prefix -- perhaps that is the
problem with chmod?

Lastly, note I am using WinXP Home edition -- which has limited
user admin/acl features. For example, the Security tab in file
properties is missing (though I can add that via a download from
Microsoft). But it seems to have limited ability to add users to
groups and so forth, so the Security tab seems to have marginal
value anyway.

Cheers,
Raman

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: 1.7.1-1 noacl on samba share has incorrect directory write bit

Corinna Vinschen-2
On Jan  9 10:05, Raman Gupta wrote:
> One thing I'm not certain about is why mkpasswd returns my username
> twice, once with a "Unix User" prefix and once with "SERVER" prefix
> -- I note your example does not do that:
>
> $ mkpasswd -L server -S_ -U root,raman
> Unix User_root:unused:10000:99999:,S-1-22-1-0::
> Unix User_raman:unused:10500:99999:,S-1-22-1-500::
> SERVER_raman:unused:11000:10513:Raman Gupta,U-SERVER\raman,S-1-5-21-903485053-2526882046-1379677160-1000://server/raman:/bin/bash

I don't know.  It's something in your Samba setup, perhaps.

> Lastly, note I am using WinXP Home edition -- which has limited
> user admin/acl features. For example, the Security tab in file
> properties is missing (though I can add that via a download from
> Microsoft). But it seems to have limited ability to add users to
> groups and so forth, so the Security tab seems to have marginal
> value anyway.

Only the GUI is crippled in XP Home.  From the comand line everything
works fine.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: 1.7.1-1 noacl on samba share has incorrect directory write bit

G.W. Haywood
In reply to this post by Raman Gupta
Hi there,

On Sun, 10 Jan 2010 Corinna Vinschen wrote:

> Only the GUI is crippled in XP Home.  From the comand line
> everything works fine.

I had been under the impression that XP Home would not permit the
machine to join a Windows Active Directory domain.  Is that wrong?
Is this simply a feature of the crippled GUI?

--

73,
Ged.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: 1.7.1-1 noacl on samba share has incorrect directory write bit

Corinna Vinschen-2
On Jan 10 12:48, G.W. Haywood wrote:

> Hi there,
>
> On Sun, 10 Jan 2010 Corinna Vinschen wrote:
>
> > Only the GUI is crippled in XP Home.  From the comand line
> > everything works fine.
>
> I had been under the impression that XP Home would not permit the
> machine to join a Windows Active Directory domain.  Is that wrong?
> Is this simply a feature of the crippled GUI?

No, that's really crippled.  I was talking about the security stuff
and manipulating users and groups in the local SAM.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: 1.7.1-1 noacl on samba share has incorrect directory write bit

Raman Gupta
In reply to this post by Corinna Vinschen-2
On 01/10/2010 06:00 AM, Corinna Vinschen wrote:

> On Jan  9 10:05, Raman Gupta wrote:
>> One thing I'm not certain about is why mkpasswd returns my username
>> twice, once with a "Unix User" prefix and once with "SERVER" prefix
>> -- I note your example does not do that:
>>
>> $ mkpasswd -L server -S_ -U root,raman
>> Unix User_root:unused:10000:99999:,S-1-22-1-0::
>> Unix User_raman:unused:10500:99999:,S-1-22-1-500::
>> SERVER_raman:unused:11000:10513:Raman Gupta,U-SERVER\raman,S-1-5-21-903485053-2526882046-1379677160-1000://server/raman:/bin/bash
>
> I don't know.  It's something in your Samba setup, perhaps.

I see no obvious reason for it but then its not clear to me what
mkpasswd "asks" Samba for when generating this list. In any case, do
you think this is the cause of the chmod problem I am having?

>> Lastly, note I am using WinXP Home edition -- which has limited
>> user admin/acl features. For example, the Security tab in file
>> properties is missing (though I can add that via a download from
>> Microsoft). But it seems to have limited ability to add users to
>> groups and so forth, so the Security tab seems to have marginal
>> value anyway.
>
> Only the GUI is crippled in XP Home.  From the comand line everything
> works fine.

Ok -- but does it matter? I'm sorry, but its really not clear to me
what I need to do to get acl's on samba to work in a non-domain
environment.

Cheers,
Raman

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple