Bug 1810 - Suggeste rewording of man smb.conf: inherit acls, permissions
Summary: Suggeste rewording of man smb.conf: inherit acls, permissions
Status: RESOLVED WONTFIX
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Docs (show other bugs)
Version: 3.0.6
Hardware: All All
: P3 normal
Target Milestone: none
Assignee: John H Terpstra (mail address dead(
QA Contact: Samba Documentation QA Contact~
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-22 10:32 UTC by Clock
Modified: 2010-04-26 03:40 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Clock 2004-09-22 10:32:00 UTC
Having encountered severe frustration, ambiguity and incorrect factual content
during my tries to understand inherit acls and inherit permissions sections of
man smb.conf, I am suggesting a hopefully clear and elegant rewording of them.

I am not sure if all details are correct. Please correct them if they are
factually wrong.

inherit acls (S)
inherit permissions (S)

        These two options control the processing of permissions of newly
        created files or directories between client's request and actual
        creation of the file/directory on the local filesystem.

        The process begins with client asking (either implicitly or explicitly
        Samba to create a file. The client always supplies a file permission
        vector basically similar to plain UNIX permission bit vector. At the
        end of the process, Samba calls appropriate system call which,
        regardless of whether the filesystem is an ACL or plain old UNIX one,
        requires a plain old UNIX permission string.

        The resulting file's/directory's permissions or ACL is a result of
        creating the file using underlying operating system call with
        <em>mode</em> parameter resulting from process described below, and
        with umask set to 0. See corresponding UNIX and ACL documentation for
        the rules that apply.

        Further, mode represents the permission string being gradually
        processed.

        1. mode is assigned what client asks us to create

        2. if inherit permissions is set to "no", then certain permissions are
        revoked from mode by application of create mask (for files) or
        directory mask (for directories).

        3. if inherit permissions is set to "no", then certain permissions are
        granted into mode by application of force create mode (for files) or
        force directory mode (for directories).

        4. if inherit permissions is set to "yes" and the object to be created
        is a directory, mode is set from parent directory's permissions
        including bits such as setgid, but excluding setuid. Setuid is set to
        zero.

        5. if inherit permissions is set to "yes" and the object to be created
        is a file, all bits including bits like setgid with exception of
        execute and setuid bits are copied from parent directory. Setuid bit is
        set to zero.

        5. if inherit acls is set to "yes" and the filesystem is an ACL one and
        the parent directory has a default acl, the mode is set to 0777.  This
        causes verbatim copy of default ACL to be propagated, as implies from
        ACL documentation.

        Now, the system call itself is called, with <em>mode</em> as parameter
        and with umask set to 0.

        SEE ALSO: man creat, open, mkdir, acl.
Comment 1 John H Terpstra (mail address dead( 2004-11-23 08:55:58 UTC
EMailed JRA for comment on this. I'll review later. - JHT
Comment 2 Gerald (Jerry) Carter (dead mail address) 2005-02-01 12:01:31 UTC
updating qa contact
Comment 3 Stefan Metzmacher 2010-04-26 03:40:20 UTC
John, is you still want to include it, please reopen the bug