Hi Miguel,
On Wed, Feb 04, 2009 at 12:22:58AM +, Miguel Medalha wrote:
Here is the patch I've committed to the 3.3 code tree
for this problem. It will be in the next release. Please
try it out and let me know if it fixes your problem (it
does here).
Thank you so much!
Will Sernet
On Fri, Jan 30, 2009 at 07:24:34PM +, Miguel Medalha wrote:
Is behavior of ACLs under Samba 3.3.0 (Sernet) completely different from
that under version 3.2.7? The release notes only talks about some
fixes.
I installed version 3.3.0 and got completely different result with the
same
Here is the patch I've committed to the 3.3 code tree
for this problem. It will be in the next release. Please
try it out and let me know if it fixes your problem (it
does here).
Thank you so much!
Will Sernet provide a 3.3.0-38 version as they did with 3.2.7?
--
To unsubscribe from this
Hi Miguel,
On Mi, Feb 04, 2009 at 12:22:58 +, Miguel Medalha wrote:
Here is the patch I've committed to the 3.3 code tree
for this problem. It will be in the next release. Please
try it out and let me know if it fixes your problem (it
does here).
Thank you so much!
Will Sernet
Is behavior of ACLs under Samba 3.3.0 (Sernet) completely different from
that under version 3.2.7? The release notes only talks about some fixes.
I installed version 3.3.0 and got completely different result with the
same filesystem and the exact same samba configuration. The ACLs behaved
On Fri, Jan 30, 2009 at 07:24:34PM +, Miguel Medalha wrote:
Is behavior of ACLs under Samba 3.3.0 (Sernet) completely different from
that under version 3.2.7? The release notes only talks about some
fixes.
I installed version 3.3.0 and got completely different result with the
same
On Fri, Jan 30, 2009 at 11:43:04AM -0800, Jeremy Allison wrote:
Not yet, it's on my list of things to document and
discuss in a talk at SambaXP this year.
As you mention it -- did I miss your talk submitted?
Volker
pgpsFkI5d4z9U.pgp
Description: PGP signature
--
To unsubscribe from this
On Fri, Jan 30, 2009 at 08:50:50PM +0100, Volker Lendecke wrote:
On Fri, Jan 30, 2009 at 11:43:04AM -0800, Jeremy Allison wrote:
Not yet, it's on my list of things to document and
discuss in a talk at SambaXP this year.
As you mention it -- did I miss your talk submitted?
Just hit the
On Fri, Jan 30, 2009 at 11:58:16AM -0800, Jeremy Allison wrote:
On Fri, Jan 30, 2009 at 08:50:50PM +0100, Volker Lendecke wrote:
On Fri, Jan 30, 2009 at 11:43:04AM -0800, Jeremy Allison wrote:
Not yet, it's on my list of things to document and
discuss in a talk at SambaXP this year.
Much of the ACL code has been rewritten to allow underlying
filesystems to implement native NT ACLs directly (...)
Good!
but the functionality should be the same as 3.2.x when not
using the experimental ACL modules.
I am not using the ACL modules and the functionality is definitely
Miguel Medalha wrote:
Much of the ACL code has been rewritten to allow underlying
filesystems to implement native NT ACLs directly (...)
Good!
but the functionality should be the same as 3.2.x when not
using the experimental ACL modules.
I am not using the ACL modules and the
On Fri, Jan 30, 2009 at 03:35:24PM -0500, Ryan B. Lynch wrote:
Miguel Medalha wrote:
Much of the ACL code has been rewritten to allow underlying
filesystems to implement native NT ACLs directly (...)
Good!
but the functionality should be the same as 3.2.x when not
using the experimental
I would describe the problem *slightly* differently from Miguel. I do
not think that ACLs are the real problem, because the bug behaviour
exists regardless of whether you're using filesystem ACLs or not.
You may be right. I didn't have the time to thoroughly test it because I
had to
On Fri, Jan 30, 2009 at 01:25:02PM -0800, Jeremy Allison wrote:
I would describe the problem *slightly* differently from Miguel. I do
not think that ACLs are the real problem, because the bug behaviour
exists regardless of whether you're using filesystem ACLs or not.
The problem
What your users can do with the file over Samba hasn't actually changed,
is they have write access to the directory they can still delete
the file, but the ACLs look funny.
No, they can't. I was alerted to this problem precisely because users
who have full access to the directory
On Fri, Jan 30, 2009 at 09:59:58PM +, Miguel Medalha wrote:
What your users can do with the file over Samba hasn't actually changed,
is they have write access to the directory they can still delete
the file, but the ACLs look funny.
No, they can't. I was alerted to this problem
How are they trying to delete the files ? Using Windows explorer or
cmd.exe or a custom app ?
Using Windows Explorer. This is a CentOS machine serving a network of
Windows XP workstations.
--
To unsubscribe from this list go to the following URL and read the
instructions:
Jeremy Allison wrote:
On Fri, Jan 30, 2009 at 01:25:02PM -0800, Jeremy Allison wrote:
I would describe the problem *slightly* differently from Miguel. I do
not think that ACLs are the real problem, because the bug behaviour
exists regardless of whether you're using filesystem ACLs or
On Fri, Jan 30, 2009 at 10:03:57PM +, Miguel Medalha wrote:
How are they trying to delete the files ? Using Windows explorer or
cmd.exe or a custom app ?
Using Windows Explorer. This is a CentOS machine serving a network of
Windows XP workstations.
Can you give me an exact
On Friday 30 January 2009 15:53:08 Jeremy Allison wrote:
On Fri, Jan 30, 2009 at 01:25:02PM -0800, Jeremy Allison wrote:
I would describe the problem *slightly* differently from Miguel. I do
not think that ACLs are the real problem, because the bug behaviour
exists regardless of whether
On Fri, Jan 30, 2009 at 05:08:14PM -0500, Ryan B. Lynch wrote:
I tested this about four weeks ago, comparing operations from Windows
clients against our Samba 3.2.7 server and another machine running a
3.3.0 pre-release checkout. The ACL rights assignments did appear to be
different,
Volker's changes are correct, in that delete access in POSIX does not
belong to a file itself, but to the containing directory. So really
we should remove the DELETE_ACCESS bit from both the file and the
directory ACL returned.
Without having the deep knowledge you have about this, it seems
On Fri, Jan 30, 2009 at 10:32:55PM +, Miguel Medalha wrote:
Volker's changes are correct, in that delete access in POSIX does not
belong to a file itself, but to the containing directory. So really
we should remove the DELETE_ACCESS bit from both the file and the
directory ACL returned.
Can you give me an exact scenario to reproduce. I can certainly
delete files I have created in my test env.
I have a directory from which getfacl --t obtains the following:
USER Adminrwx rwx
GROUP Admins rwx rwx
group Admins rwx rwx
group Editores rwx rwx
On Fri, 2009-01-30 at 14:43 -0800, Jeremy Allison wrote:
On Fri, Jan 30, 2009 at 10:32:55PM +, Miguel Medalha wrote:
Volker's changes are correct, in that delete access in POSIX does not
belong to a file itself, but to the containing directory. So really
we should remove the
Effectively, we should remove the map acl full control parameter as it now
longer
has any use except to break things. I'll mark it deprecated with the patch.
Yes, I suppose you are right.
Thank you for your efforts. I really appreciate your work.
--
To unsubscribe from this list go to
On Fri, Jan 30, 2009 at 10:49:35PM +, simo wrote:
Jeremy, would it make sense to set the delete bit (or even full control)
depending on whether the user has write control over the parent
directory ?
Doing this right now...
--
To unsubscribe from this list go to the following URL and
On Fri, Jan 30, 2009 at 01:53:08PM -0800, Jeremy Allison wrote:
Volker's changes are correct, in that delete access in POSIX does not
belong to a file itself, but to the containing directory. So really
we should remove the DELETE_ACCESS bit from both the file and the
directory ACL returned.
28 matches
Mail list logo
