Corinna,
This patch implements __{u,g}id32_t in sec_acl.cc and performs a
few optimizations using the new argument of internal_getgroups,
cygpsid and strechr.
is_grp_member is now unused and will disappear in the next installment.
Three remarks:
1) I changed a STANDARD_RIGHTS_ALL to
On Wed, Feb 05, 2003 at 09:15:05AM -0500, Pierre A. Humblet wrote:
> is_grp_member is now unused and will disappear in the next installment.
You did it ;-)
> Three remarks:
> 1) I changed a STANDARD_RIGHTS_ALL to STANDARD_RIGHTS_WRITE in setacl.
>Is that what you meant?
I don't know what you
At 03:50 PM 2/5/2003 +0100, Corinna Vinschen wrote:
>> 1) I changed a STANDARD_RIGHTS_ALL to STANDARD_RIGHTS_WRITE in setacl.
>>Is that what you meant?
>
>I don't know what you mean by "Is that what you meant?". What are you
>referring to? However, it's incorrect. The permission to write do
On Wed, Feb 05, 2003 at 10:22:39AM -0500, Pierre A. Humblet wrote:
> Well, that's more generous than alloc_sd.
> In particular Everyone gets the right to change the modes or take ownership,
> whenever it gets the right to write.
Oh, I see what you mean. Well...
... I've checked your patch in to
At 05:16 PM 2/5/2003 +0100, Corinna Vinschen wrote:
>... I've checked your patch in together with a patch from me. It
>should now be most similar to alloc_sd(). At least I hope so...
Yes, that's fine.
However one question remains (in setacl and alloc_sd):
what good does it do to remove DELETE
On Wed, Feb 05, 2003 at 11:29:40AM -0500, Pierre A. Humblet wrote:
> what good does it do to remove DELETE if unlink() does a
> chmod(777) anyway, which puts it back?
$ touch foo
$ rm foo
$ touch foo
$ chmod u-w foo
$ rm foo
rm: remove write-protected file `foo'? y
$
Corinna
--
Corinna Vinschen
On Wed, Feb 05, 2003 at 05:37:38PM +0100, Corinna Vinschen wrote:
> On Wed, Feb 05, 2003 at 11:29:40AM -0500, Pierre A. Humblet wrote:
> > what good does it do to remove DELETE if unlink() does a
> > chmod(777) anyway, which puts it back?
>
> $ touch foo
> $ rm foo
> $ touch foo
> $ chmod u-w foo
At 05:37 PM 2/5/2003 +0100, Corinna Vinschen wrote:
>On Wed, Feb 05, 2003 at 11:29:40AM -0500, Pierre A. Humblet wrote:
>> what good does it do to remove DELETE if unlink() does a
>> chmod(777) anyway, which puts it back?
>
>$ touch foo
>$ rm foo
>$ touch foo
>$ chmod u-w foo
>$ rm foo
>rm: remove
At 05:45 PM 2/5/2003 +0100, Corinna Vinschen wrote:
>But still, it's more correct, isn't it.
That's opinion, not fact! It's also relatively convoluted code that does
little, or perhaps even nothing!
>Surprise, surprise. I've just tried to delete a file in Explorer with
>the DELETE bit unset and
On Wed, Feb 05, 2003 at 12:02:01PM -0500, Pierre A. Humblet wrote:
> At 05:45 PM 2/5/2003 +0100, Corinna Vinschen wrote:
> >But still, it's more correct, isn't it.
> That's opinion, not fact! It's also relatively convoluted code that does
> little, or perhaps even nothing!
No problem, then it's m
At 06:13 PM 2/5/2003 +0100, Corinna Vinschen wrote:
>
>When DELETE_CHILD is off on the parent dir, a file with DELETE can be
>removed, a file w/o DELETE can't.
OK, that's what I see with Explorer. However rm will delete it.
That's why I don't think ~DELETE is such a good idea, it only
affects Win
Corinna,
Here are the changes to security.cc and sec_acl.cc to use
well_known_creator_xxx_sid.
They seem to work fine on NT4.
There is peculiar effect: if a directory was created e.g. 427 by
a ntsec user with uid != gid and a file is created in the directory by
a Windows user with gid == uid
Hi Pierre,
On Mon, Dec 16, 2002 at 10:31:16AM -0500, Pierre A. Humblet wrote:
> I have a question: there is code in setacl (new line 139) to merge non-default
> ACE's with previous default ACEs.
> As the acl was sorted, I don't see how that code can ever be exercised.
> Should we try to merge def
Corinna Vinschen wrote:
>
> Hi Pierre,
>
> On Mon, Dec 16, 2002 at 10:31:16AM -0500, Pierre A. Humblet wrote:
> > I have a question: there is code in setacl (new line 139) to merge non-default
> > ACE's with previous default ACEs.
> > As the acl was sorted, I don't see how that code can ever be e
"Pierre A. Humblet" wrote:
> But frankly I don't understand why it happens!
OK, I do now. The code is looking forward to entries that
are not yet processed.
Pierre
> "Pierre A. Humblet" wrote:
>
> > But frankly I don't understand why it happens!
>
> OK, I do now. The code is looking forward to entries that
> are not yet processed.
... and thus it may merge entries for the current owner and
for the default owner (creator_owner). Ditto for groups.
That's not
On Mon, Dec 16, 2002 at 01:26:31PM -0500, Pierre A. Humblet wrote:
> ... and thus it may merge entries for the current owner and
> for the default owner (creator_owner). Ditto for groups.
What? How should it? It only merges entries with the same uid/gid
and with the same type (USER/GROUP). It w
erre
2002/12/16 Pierre Humblet <[EMAIL PROTECTED]>
* sec_acl.cc (search_ace): Make id == -1, instead of < 0, special.
(setacl): Use well_known_creator for default owner and owning group
and do not merge non-default with default in these cases.
(getacl):
Corinna Vinschen wrote:
>
> On Mon, Dec 16, 2002 at 01:26:31PM -0500, Pierre A. Humblet wrote:
> > ... and thus it may merge entries for the current owner and
> > for the default owner (creator_owner). Ditto for groups.
>
> What? How should it? It only merges entries with the same uid/gid
> and
Hello Corinna,
No outstanding question this time, from my side at least...
Pierre
2002/12/16 Pierre Humblet <[EMAIL PROTECTED]>
* sec_acl.cc (search_ace): Use id == -1, instead of < 0, as wildcard.
(setacl): Use well_known_creator for default owner and own
tion is to invalidate the type of entry 4 after matching,
instead of resetting it to 0.
The patch below is incremental to what I sent last night.
Pierre
2002/12/17 Pierre Humblet <[EMAIL PROTECTED]>
* sec_acl.cc (setacl): Invalidate the a_type of matching
default entries, instea
up:[id]:rwx,
default:mask::rwx,
default:other::rwx,
Best regards,
Silvio Laguzzi
---
Silvio Laguzzi
Zimmer-AL GmbH
Junkersstrasse 9
D-89231 Neu-Ulm
http://www.data-al.de
--- sec_acl-orig.cc 2006-07-18 17:52:13.421875000 +0200
+++ sec_acl.cc 2006-07-20 09:20:27.56250 +0200
@@ -727,7 +727,7 @@ aclt
Hi Silvio,
On Jul 20 09:26, Silvio Laguzzi wrote:
> Hi, all
>
> when parsing ACL entries from an input string with aclfromtext32() the
> ACL rights follow at different position after the ACL entry tags like
> default:user, user, group, mask and so on. For almost all of the tags
> this position
23 matches
Mail list logo
