2.0.7: inherit permissions = yes breaks setting read-only on files

[Robert Dahlem]

David,

[samba mailing list dropped here too]

On Thu, 24 Aug 2000 17:18:21 +0100 (BST), David Lee wrote:

>The discussion seems OK, but it might just be worth this 
>clarification of the *intention* of "inherit permissions".
>
>The "inherit permissions" functionality was new at 2.0.7 so bugs 
>might still lurk.  Its intended behaviour (as distinct from what a 
>particular OS might actually do) is: 
>
>o  new file: inherit read/write bits from its directory (in most UNIX
>   systems, this is "push the directory's bits through a a 0666 
>   mask". It leaves the "x" bits free to follow Samba's "map 
>   archive" etc. interpretation.

That seems to be what it does.

>o  new directory:  inherit all r/w/x, setgid (g+s) and sticky (+t) 
>   bits from parent directory.  It specifically doesn't inherit 
>   setuid (at present at least).

That IS what it does (at the moment, meaning 2.0.7 release code).

The opposite thing was the origin of the discussion: With "inherit
permissions = no" the SGID bit was not inherited when creating new
directorys although the operating system should provide the
functionality. 

Meanwhile it's clear that "inherit permissions" is innocent in this
point: the behaviour is not caused by smbd/dosmode.c (your code) but in
lib/doscalls.c by a broken dos_mkdir(). Most likely you had no way to
discover this when you developped the code as your development was
based on 2.0.6, where dos_mkdir() was not broken.


The problem with "inherit permissions = yes" is that it effectively
prevents setting the read-only attribute (dropping the w-bit(s)) on
existing files.

All the documentation tells that it only will have effects on newly
created things but it insists on chmod-ing with the parent directories
attributes whenever you fiddle with attributes from the clients side.

>(There was also a discussion a few months ago about a detail of
>directory+setgid: whether (and if so, how) to force group-owner
>inheritance, which some systems do naturally.  But that is another
>story...)

My $0.02 on this is: have a look at what the unix administrator
intended when he did "chmod g+s" on the directory. It was his/her
decision and samba should not fiddle around in this place.

Regards,
        Robert

---------------------------------------------------------------
Robert.Dahlem at gmx.net           Fax +49-69-432647
---------------------------------------------------------------