Page MenuHomePhabricator

replica.my.cnf and .kube/config is not readable by the group members
Closed, DeclinedPublic

Description

T158568 brought up that replica.my.cnf and .kube/config files for tool accounts are owned by the tool account's user and group, i. e. (in general) accessible by the tool maintainers (= group members), but due to the permissions -r-------- only readable by the tool account itself. This means that to read this file, tool maintainers must use become or sudo to switch to the tool account whereas for all other files they can just use their normal ways.

IMHO they should be -r--r----- instead, i. e. readable by the tool account and the members of its group. (NB: I don't have problems accessing these files with -r--------; I'm thinking about tool maintainers for whom the extra step is not just a nuisance.)

The permissions are set in modules/role/files/labs/db/maintain-dbusers.py:

120     f = os.open(file_path, os.O_CREAT | os.O_WRONLY | os.O_NOFOLLOW)
121     try:
122         os.write(f, replica_buffer.getvalue().encode('utf-8'))
123         # uid == gid
124         os.fchown(f, uid, uid)
125         os.fchmod(f, 0o400)
126 
127         # Prevent removal or modification of the credentials file by users
128         subprocess.check_output(['/usr/bin/chattr', '+i', file_path])
129     except:
130         os.remove(file_path)
131         raise
132     finally:
133         os.close(f)

and modules/toollabs/files/maintain-kubeusers:

242     f = os.open(path, os.O_CREAT | os.O_WRONLY | os.O_NOFOLLOW)
243     try:
244         os.write(f, json.dumps(config, indent=4, sort_keys=True).encode('utf-8'))
245         # uid == gid
246         os.fchown(f, int(user.id), int(user.id))
247         os.fchmod(f, 0o400)
248         logging.info('Write config in %s', path)
249     except:
250         logging.exception()
251         raise
252     finally:
253         os.close(f)

Note that in the case of maintain-dbusers.py, after T158420 is fixed, the permissions and the assigned group depend on whether the user is a tool account (0o440) or not (0o400) as non-tool accounts are all members of the wikidev group and no per-user groups exist for those users.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

only readable by the tool account itself

... but why should it be readable by the group? The credentials are supposed to be used by only the tool account. I remember @yuvipanda resetting replica.my.cnf for the personal accounts that use credentials from tool accounts. Besides, if it's needed by other tool accounts, these other tool accounts have their own credentials anyways; there is no need to share. (And we don't encourage too much use from personal accounts.)

I'm thinking about tool maintainers for whom the extra step is not just a nuisance

Could you name one workflow that requires these files to be readable/writable by the group? These credential files aren't unique in setting group permissions to 0; dotfiles like .bash_history does this by default as well. And, IMO, those read-all-files workflows like backing up should be able to handle unreadable files gracefully.

scfc closed this task as Declined.EditedFeb 21 2017, 12:52 AM

I think it can be surprising as I believe it is intended that maintainer accounts have complete and transparent control over tool account's home directories. No workflows require this, and this does not block anything, it's just an oddity.

That group permissions for .bash_history & Co. are --- is due to the same umask being used for user and tool accounts (T48468), i. e. an "error" noone bothered to fix. But you have a point: With umask being 0022 for tool accounts, this would be playing whac-a-mole as new files created by the tool account will not be readable by the maintainer accounts either, so replica.my.cnf and .kube/config are just two of many.