Re: Rehashing My File Permissions Understanding(or lack of it)

From: Paul Howarth (paul_at_city-fan.org)
Date: 08/31/05

  • Next message: brouwers roland lx: "why does nobody give an answer on question conc.evolution"
    Date: Wed, 31 Aug 2005 09:59:00 +0100
    To: For users of Fedora Core releases <fedora-list@redhat.com>
    
    

    Mark Sargent wrote:
    > Paul Howarth wrote:
    >
    >> Jay Paulson wrote:
    >>
    >>> I was under the impression that changing the umask was a possible
    >>> security risk. Am I correct in thinking that?
    >>
    >>
    >>
    >> Possibly, possibly not. Using a umask of 002 instead of 022 is
    >> something that Red Hat/Fedora specifically cater for. What this means
    >> is that woth a umask of 002, files are created with group write
    >> permissions by default, so if your default group is shared with a
    >> number of other people then they will be able to write to your files
    >> by default. However, in Red Hat/Fedora, every new user is created with
    >> their own group by default, which isn't shared with any other user. So
    >> enabling group write permission isn't a big issue. What this then lets
    >> you do is to create a separate group for shared data, and then
    >> everyone's default umask being 002 (if set that way) then makes it
    >> easy for all members to create and edit files with this shared groupid.
    >>
    >> Paul.
    >>
    > Hi All,
    >
    > so, in theory, if there were a way to set a umask specifically for a
    > certain group, it'd be great. For example; when user xman, who is a
    > member of say, share2 group, creates a new file in a particular dir, the
    > new file would be writable by all within that same group. Would that
    > just make things too messy, OR, am I just not getting it.? Cheers.

    You're right that this would be great, but unfortunately I don't know of
      any way of implementing it.

    Well, actually that's not quite true. Using samba you can do things like
    this by forcing permissions and uids/gids. But for access to local files
    and directories, I don't know of a way of doing this in a
    directory-specific way.

    Do note thought that if your users all have their own groups, as is the
    default in Red Hat/Fedora, you should be safe to set the umask to 002
    for all users. If you then create a directory /path/to/dir and do:

    # chgrp share2 /path/to/dir
    # chmod g+s /path/to/dir

    then any files/directories created in that directory should get the
    right group ID and permissions.

    Paul.

    -- 
    fedora-list mailing list
    fedora-list@redhat.com
    To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
    

  • Next message: brouwers roland lx: "why does nobody give an answer on question conc.evolution"

    Relevant Pages

    • Re: File Sharing (again - sorry, Pd)
      ... InTerminal, type umask. ... Back in the good old days, Mac OS X user accounts ... The reason that the file permissions are "resetting" each time the ... that folder inherit the ACLs from the folder. ...
      (uk.comp.sys.mac)
    • Re: umask?
      ... setgid permissions used on your files and directories. ... the default umask value set on your system to 027, ... The shell does simple maths to determine what permissions are used on ... On a directory the maximum permissions will be drwxrwxrwx. ...
      (Fedora)
    • Re: [patch 12/13] ACL umask handling workaround in nfs client
      ... >> the umask locally, and sends the effective permissions to the server. ... >> only the default ACL determines the file's effective permissions. ...
      (Linux-Kernel)
    • Re: File Permissions problem : Cry for HELP
      ... is something wrnog with the server cause when i upload the same files from ... >> i have a problem with file permissions, each new file i need to create i ... >> Internal Server Error ... > You need to change the umask used when you are saving web files. ...
      (Fedora)
    • Re: default permissions when scping files
      ... >> username take on specific permissions, or barring that, ... I read it to mean that the umask does not affect the execute bit of files ... as the source file has. ...
      (comp.unix.shell)