851305 - releng-puppet1.srv.releng.scl3.mozilla.com has a default umask of 027

Status: RESOLVED INVALID

(Infrastructure & Operations :: Infrastructure: Puppet, task)

Description

[Aki Sasaki (not active)]

from /etc/bashrc:
if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
    umask 0027
else
    umask 022
fi

It's problematic to have a default umask of 0027 when we're uploading python packages that go live immediately.  When tests install package X (without a version specified), they try to download an unreadable pacakge, and the tree burns.

Can we change this?  I already have a |umask 002| in my .bashrc, but this burnt the tree when Armen uploaded something.  We can certainly script or doc around this, but that seems to defeat the purpose of setting this default.

Comment 1

[Dustin J. Mitchell [:dustin] (he/him)]

This umask is an infra-wide default.  I don't think we should change it globally for this reason.

The 'puppetagain-fixperms' script will fix this up, so perhaps just document that you should run that immediately after uploading.  It runs every half-hour in a crontask anyway.

Tests really shouldn't be installing a package "X" without a version specified, but for situations where that's the case, I think some caution is advised anyway.  Certainly we could add a "puppetagagain-python-package" script that would Do The Right Thing from the start (change the perms first, then move the file into place).

I'm assigning to you, Aki, as a way of saying "patches accepted".

Comment 2

[Aki Sasaki (not active)]

Is there a way to make an exception to the infra-wide default?

Comment 3

[Hal Wine [:hwine] use NI!]

(In reply to Dustin J. Mitchell [:dustin] from comment #1)
> This umask is an infra-wide default.  I don't think we should change it
> globally for this reason.

I'm confused - we're not asking for a global change, we're asking for a change on all infra managed puppet masters within the releng network.

Could you clarify the concern please when you point us to exception request process asked for in comment 2? 

Thanks! (and back to relops)

Comment 4

[Dustin J. Mitchell [:dustin] (he/him)]

I meant globally to the host, not globally to the company.

This is best fixed with a better process for adding files, rather than changing the umask on the host (which affects more than just adding files to this directory).

Comment 5

[Aki Sasaki (not active)]

I think a host that's designed for serving files via the web, having a default that makes serving those files impossible without additional steps run every time, doesn't make sense.  So I disagree on not making this change globally on the host.

We do have a workaround, which would make this lower urgency; I'd just like the right fix, should we agree on what that fix should be.

Comment 6

[Dustin J. Mitchell [:dustin] (he/him)]

This host also serves a lot of secret data.  I'd rather have a public file non-readable, than a secret file accidentally readable.

Comment 7

[Hal Wine [:hwine] use NI!]

(In reply to Dustin J. Mitchell [:dustin] from comment #6)
> This host also serves a lot of secret data.  I'd rather have a public file
> non-readable, than a secret file accidentally readable.

Agreed, although that's a design flaw :( -- is a stricter separation of privileged data part of puppet again architecture? Or do we need a bug there?

Comment 8

[Dustin J. Mitchell [:dustin] (he/him)]

It's not a design flaw.  Puppet by its nature deals with both public and private data.

Comment 9

[:Atoll]

And, releng-puppet1 is gone away, so RESO INVA unless someone sees a need to reopen this for a new set of hosts.