Re: DB_VERB_CHKPOINT is gone

Hi,
Le vendredi 27 juin 2008 à 01:11 -0400, Adam Goode a écrit :
> Hi,
> 
> DB_VERB_CHKPOINT is gone since 2005 from Berkeley DB. When building with 
> transactions, compilation fails.
> 
> Here is a patch to remove this option.
checked in, thanks

Didier

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: [patch] papd -d doesn't write to stderr

Hi,
Le jeudi 06 mars 2008 à 12:34 +0100, Martin Nagy a écrit :
> Hi,
> man page for papd says that when papd is invoked with -d flag, it will 
> not fork and will write debugging information to stderr. It doesn't 
> fork, but it doesn't write any debugging information to stderr. The 
> attached patch fixes the problem. Could this please be included in CVS 
> HEAD? Thanks.
Checked in, thanks
Didier

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Permission semantics: inherited privs with UNIX privs and strict POSIX privs

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Netatalk-devel mailing list
Netatalk-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netatalk-devel

Re: Permission semantics: inherited privs with UNIX privs and strict POSIX privs

I agree with this completely, although I haven't parsed the diff file.

The default netatalk behaviour has differed from Mac OS X, and I've  
never understood why that needs to be (although simulating earlier Mac  
AFP servers needs to exist also).

Not setting upriv on a volume is the number one problem that is  
reported with the afpfs-ng client.  It is to the point now where I'll  
incorporate a patch that checks if the server is netatalk, and if it  
witnesses unusual priv behaviour suggests that the user look at the  
upriv config option in the logs.

- Alex

On 13-Aug-08, at 6:19 AM, Frank Lahm wrote:

> Hello netatalk-devel,
>
> proposal:
> netatalk should activate AFP 3.1 UNIX privileges by default as all  
> other available AFP implementations do.
>
> Taking Apples afpd as a reference:
> Apple's afpd supports two permission modes: POSIX mode and inherited  
> privileges. Both supporting UNIX privileges. Inherited privileges  
> are /somehow/ implemented at the server side.
>
> Attached is a patch for netatalk head that tries to mimic that.
>
> In order to preserve current inherited semantics, on top of UNIX  
> privileges a inherited permissions model is implemented by
> - inheriting privileges (as already implemented in netatalk) and
> - ignoring any mode changing calls from clients
> unless a new volume preference "posix" enables them giving POSIX  
> semantics.
>
> UNIX privileges can be deactivated on a per volume basis with  
> another new preference "noupriv", "upriv" is set by default.
>
> Patch overview (best viewed monospaced):
>
> FILE                        FUNCTION            DESCRIPTION
> ==================================================================
> etc/afpd/main.c             main                set umask to 0!  
> later we must apply requested umask
>                                                 manually in any  
> effected codepath
> etc/afpd/directory.c        afp_createdir       new "vol" arg to  
> netatalk_mkdir call
>                             netatalk_mkdir      changed prototype:  
> must include volume;
>                                                 call ad_mkdir with  
> applied saved umask and volume umask
>                             copydir             add vol arg to  
> netatalk_mkdir call
>                             setdirparams        in case  
> DIRPBIT_UNIXPR test if request is for a POSIX
>                                                 volumes (new volume  
> option), only proceed if it is
> etc/afpd/file.c             afp_createfile      apply saved umask  
> and volume umask
>                             setfilparams        in case  
> FILPBIT_UNIXPR test if request is for a POSIX
>                                                 volumes (new volume  
> option), only proceed if it is
> etc/afpd/unix.c             stickydirmode       do not apply umask
>                             setfilunixmode      ignore if not a  
> POSIX volume even if we have further callers
>                                                 like FPExchangeFiles  
> that want to apply modes. We rely
>                                                 on the fact that  
> files and dirs have to be created with
>                                                 correct mode in the  
> first place!
>                             setfilmode          do not apply umask
>                              setdirunixmode     if !POSIX vol:  
> unchanged
>                                                 if POSIX: no sticky  
> stuff, chmod directly, preserve S_ISGID
> etc/afpd/volume.c           vol_opt_names[]     new: {AFPVOL_POSIX,  
> "POSIX"}
>                             volset              test volopt  
> "noupriv" and "posix"
>                             creatvol            if AFPVOL_POSIX then  
> volume->v_ad_options |= ADVOL_POSIX
>                             readvolfile         set default option  
> AFPVOL_UNIX_PRIV
> etc/afpd/volume.h           -                   #define AFPVOL_POSIX  
> (1 << 23)
> include/atalk/adouble.h     -                   #define ADVOL_POSIX  
> (1 << 4)
> libatalk/adouble/ad_open.c  NEW: ad_chgrp       change group to  
> parameter stat->st_gid
>                                                 Do I still need this?
>                             ad_open             change test for ad- 
> >ad_options & ADVOL_UNIXPRIV to
>                                                 ad->ad_options &  
> ADVOL_POSIX
>
> Patch includes updated man pages. It is tested with OS 9, 10.4 and  
> 10.5.
>
> I'd be glad If others like to chime in as I'm running out of steam.  
> Areas of further inspection should be perms of adouble files amongst  
> probably others. Seasoned netatalkers please advise.
>
> Frank
> < 
> diff 
> > 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
> Netatalk-devel mailing list
> Netatalk-devel <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/netatalk-devel

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Permission semantics: inherited privs with UNIX privs and strict POSIX privs

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Netatalk-devel mailing list
Netatalk-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netatalk-devel

Re: Permission semantics: inherited privs with UNIX privs and strict POSIX privs

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Netatalk-devel mailing list
Netatalk-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netatalk-devel

Re: Permission semantics: inherited privs with UNIX privs and strict POSIX privs

Hi,
Le mercredi 13 août 2008 à 12:19 +0200, Frank Lahm a écrit : 
> Hello netatalk-devel,
> 
> 
I know that it's not always easy but can you try to keep your patch as
small as possible with one issue/patch? 
Or maybe you didn't work on the CVS tree and only made a diff against
CVS? If it's the case I'd like to know the source used because it's
buggy. 

For example in your patch:
1) fix for a compilation error if DEBUG1 is defined (I will commit this
one). 

2) remove some gcc warning, well rather hiding them than fixing them:
- convert_string_allocate() add a (char *) cast, I'm not sure it's the
right thing to do, maybe passing a usc2_t is really bad, I'd rather keep
the warning. 

- replace mktemp with mkstemp. This one is wrong because in our case
mkstemp is 100% as insecure as mktemp and the gcc warning is badly
written: you can't replace mktemp with mkstemp, they don't have the same
semantic! mkstemp *creates* the file and now afpd leaks a file
descriptor each time afp_exchangefiles is called.

3) Remove some {} for one line if block. I don't mind them, it's just
that it makes the patch harder to read.

Now about the meat.
In my understanding you're doing three unrelated things:
1) don't apply afpd -m option (umask) in chmod,  personally I would like
to keep a way to veto client requests, we need to fix the manual with
the actual behavior though.

2) extend umask:0xxx volume parameter use. it makes a lot of sens
currently umask is rather useless.

3) I'm not sure :) 
Before we had or at least it was the idea:
upriv --> unix semantic 
!upriv --> inherited privileges

and a test (I shortcut AFPVOL_...): 
vol_unix_priv(vol) (afp_version >= 30 && ((vol)->v_flags & PRIV))

ie for pre AFP3 it's always inherited privileges.

Now
posix --> old upriv ? 
noupriv --> old !upriv ?

And something between (the default) !POSIX but PRIV which:
- doesn't return an error in set[xxxx]params if called with set unix
priv but doesn't change privileges.

- don't follow inherited privileges but unix ones each time
vol_unix_priv() is used. 

Is it what you're trying to do?  

Regards
Didier

> 
> 
> proposal:
> netatalk should activate AFP 3.1 UNIX privileges by default as all
> other available AFP implementations do.
> 
> 
> Taking Apples afpd as a reference:
> Apple's afpd supports two permission modes: POSIX mode and inherited
> privileges. Both supporting UNIX privileges. Inherited privileges
> are /somehow/ implemented at the server side.
> 
> 
> Attached is a patch for netatalk head that tries to mimic that.
> 
> 
> In order to preserve current inherited semantics, on top of UNIX
> privileges a inherited permissions model is implemented by 
> - inheriting privileges (as already implemented in netatalk) and
> - ignoring any mode changing calls from clients
> unless a new volume preference "posix" enables them giving POSIX
> semantics.
> 
> 
> 
> UNIX privileges can be deactivated on a per volume basis with another
> new preference "noupriv", "upriv" is set by default.
> 
> 
> 
> Patch overview (best viewed monospaced):
> 
> 
> FILE                        FUNCTION            DESCRIPTION
> ==================================================================
> etc/afpd/main.c             main                set umask to 0! later
> we must apply requested umask
>                                                 manually in any
> effected codepath
> etc/afpd/directory.c        afp_createdir       new "vol" arg to
> netatalk_mkdir call
>                             netatalk_mkdir      changed prototype:
> must include volume;
>                                                 call ad_mkdir with
> applied saved umask and volume umask
>                             copydir             add vol arg to
> netatalk_mkdir call
>                             setdirparams        in case DIRPBIT_UNIXPR
> test if request is for a POSIX
>                                                 volumes (new volume
> option), only proceed if it is
> etc/afpd/file.c             afp_createfile      apply saved umask and
> volume umask
>                             setfilparams        in case FILPBIT_UNIXPR
> test if request is for a POSIX
>                                                 volumes (new volume
> option), only proceed if it is
> etc/afpd/unix.c             stickydirmode       do not apply umask
>                             setfilunixmode      ignore if not a POSIX
> volume even if we have further callers
>                                                 like FPExchangeFiles
> that want to apply modes. We rely
>                                                 on the fact that files
> and dirs have to be created with
>                                                 correct mode in the
> first place!
>                             setfilmode          do not apply umask
>                              setdirunixmode     if !POSIX vol:
> unchanged
>                                                 if POSIX: no sticky
> stuff, chmod directly, preserve S_ISGID
> etc/afpd/volume.c           vol_opt_names[]     new: {AFPVOL_POSIX,
> "POSIX"}
>                             volset              test volopt
> "noupriv" and "posix"
>                             creatvol            if AFPVOL_POSIX then
> volume->v_ad_options |= ADVOL_POSIX
>                             readvolfile         set default option
> AFPVOL_UNIX_PRIV
> etc/afpd/volume.h           -                   #define AFPVOL_POSIX
> (1 << 23)
> include/atalk/adouble.h     -                   #define ADVOL_POSIX (1
> << 4)
> libatalk/adouble/ad_open.c  NEW: ad_chgrp       change group to
> parameter stat->st_gid
>                                                 Do I still need this?
>                             ad_open             change test for
> ad->ad_options & ADVOL_UNIXPRIV to
>                                                 ad->ad_options &
> ADVOL_POSIX 

> 

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Permission semantics: inherited privs with UNIX privs and strict POSIX privs

Didier,

I'm sorry, I was kind of in a rush to get the patch out of the door
finally. Therefor I overlooked some pieces when I massaged the patch
for submission.

2008/8/14 didier <dgautheron <at> magic.fr>
> I know that it's not always easy but can you try to keep your patch as
> small as possible with one issue/patch?

Of course. Shall I tidy up and resubmit?

> Or maybe you didn't work on the CVS tree and only made a diff against
> CVS? If it's the case I'd like to know the source used because it's
> buggy.

I work of CVS tree updated just before diff against CVS.

> 1) fix for a compilation error if DEBUG1 is defined (I will commit this
> one).

That one was kept inline intentionally as I was too lazy to put in in
an extra patch set. 

> 2) remove some gcc warning, well rather hiding them than fixing them:
> - convert_string_allocate() add a (char *) cast, I'm not sure it's the
> right thing to do, maybe passing a usc2_t is really bad, I'd rather keep
> the warning.

I overlooked that one.

> - replace mktemp with mkstemp. This one is wrong ...
> ... you can't replace mktemp with mkstemp, ...

I know, another oversight. I was just tired of that warning and
therefor quickly shut up gcc that way.

> 3) Remove some {} for one line if block. I don't mind them, it's just
> that it makes the patch harder to read.

Huh? Did I? Hm. I'm driving diff with -uwb, I guess that doesn't catch
brace changes... ;o)
I can clean that up and resubmit if you like.

>
> Now about the meat.
> ...

I'll reply later on these topics.

Regards
Frank

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Permission semantics: inherited privs with UNIX privs and strict POSIX privs

Now on to the meat...

I'll response with what my _intentions_ were, implementation errors set aside.

2008/8/14 didier <dgautheron <at> magic.fr>:
> Now about the meat.
> In my understanding you're doing three unrelated things:
> 1) don't apply afpd -m option (umask) in chmod,  personally I would like
> to keep a way to veto client requests, we need to fix the manual with
> the actual behavior though.

Yes. In "posix" mode we are just a transparent layer and act only on
behalf of the clients request.
We could apply umask here as well. Imo we should defer this discussion
until the more important aspects are fleshed out.
Nevertheless the patch as of now is supposed to apply -m umask option
and per volume umask when in "inheritance mode"(default).

> 2) extend umask:0xxx volume parameter use. it makes a lot of sens
> currently umask is rather useless.

Yes. While I was at it I thougth that would we nice to have.

> Before we had or at least it was the idea:
> upriv --> unix semantic
> !upriv --> inherited privileges

Yes, but out inhertied privileges mode with unix priviliges is flawed.
Apple's afpd (and as Alex says every other AFP 3.1 implementation
around) does provide inherited semantics _with_ unix privileges. So
should we.
If someone needs it, it is still  possible to define netatalk volumes
with the same semantics as before with the "noupriv" option. My
preference to change default semantics might be questiionable though
and I'm looking forward for a heated discussion on that topic.

> and a test (I shortcut AFPVOL_...):
> vol_unix_priv(vol) (afp_version >= 30 && ((vol)->v_flags & PRIV))
> ie for pre AFP3 it's always inherited privileges.

Sorry, I don't understand that one.

> Now
> posix --> old upriv ?

Yes.

> noupriv --> old !upriv ?

Exactly.

> And something between (the default) !POSIX but PRIV which:
> - doesn't return an error in set[xxxx]params if called with set unix
> priv but doesn't change privileges.

The new default is posix "off" with unix privileges "on". The
implementation then ignores any set[file|dir|filedir]params changes to
unix privileges. As we create new files and folders with inherited
privs, this combined gives inherited semantics. I've been studying
tcpdumps and ktraces of Apple's afpd for quite some time and that is
exactly whats happening there.

> - don't follow inherited privileges but unix ones each time
> vol_unix_priv() is used.

I can't remember any vol_unix_priv() calls in the code paths I effect.
What do you mean? I'll grep the code and see if that helps my memory.

> Is it what you're trying to do?

Basically I guess you got the idea, yes.

It boils down to my AppleVolumes.default which should be self-explanatory:

/Volumes/inheritedperms    "inheritedperms" umask:0002
/Volumes/posix             "posix"          options:posix
/Volumes/legacy            "legacy"         options:noupriv

I'm even running afpd with -m 0040 for testing purposes and both
umasks are applied as expected. I've verified this with the
permtest.pl submitted a few days ago. Have you noticed?

Regards
Frank

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Permission semantics: inherited privs with UNIX privs and strict POSIX privs

2008/8/15 Frank Lahm <franklahm <at> googlemail.com>:
>> - don't follow inherited privileges but unix ones each time
>> vol_unix_priv() is used.
>
> I can't remember any vol_unix_priv() calls in the code paths I effect.
> What do you mean? I'll grep the code and see if that helps my memory.

Ahh, brain fade! *That* vol_unix_priv() macro... ;o)
Hm, but: my patch removes the vol_unix_priv() check and substitutes
that with a check for (vol->v_flags & AFPVOL_POSIX). Of course a posix
volume is always a unix priv volume.
I am still not sure what your statement states.

Regards
Frank

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/