Re: PATCH: Configurable file mode mask
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: David Steele <david@pgmasters.net>
Cc: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>,
Tom Lane <tgl@sss.pgh.pa.us>, Stephen Frost <sfrost@snowman.net>,
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Adam Brightwell <adam.brightwell@crunchydata.com>
Date: 2018-01-03T13:11:25Z
Lists: pgsql-hackers
On Tue, Jan 2, 2018 at 11:43 AM, David Steele <david@pgmasters.net> wrote: >> > I think MakeDirectory() is a good wrapper, but isn't >> MakeDirectoryPerm() sort of silly? > > There's one place in the backend (storage/ipc/ipc.c) that sets non-default > directory permissions. This function is intended to support that and any > extensions that need to set custom perms. Yeah, but all it does is call mkdir(), which could just as well be called directly. I think there's a pointer to a wrapper when it does something for you -- supply an argument, log something, handle portability concerns -- but this wrapper does exactly nothing. >> + umask(~(stat_buf.st_mode & PG_DIR_MODE_DEFAULT)); >> >> Hmm, I wonder if this is going to be 100% portable. Maybe some >> obscure platform won't like an argument with all the high bits set. > > Sure - I have masked this with 0777 to clear any high bits. Sound OK? Seems a little strange to spell it that way when we're using constants everywhere else. How about writing it like this: umask(PG_DIR_MODE_DEFAULT & ~stat_buf.st_mode); I think that reads as "clear all bits from PG_DIR_MODE_DEFAULT that are not set in stat_buf.st_mode", which sounds like what we want. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Allow group access on PGDATA
- c37b3d08ca68 11.0 landed
-
Refactor dir/file permissions
- da9b580d8990 11.0 landed
-
Revert "Add basic TAP test setup for pg_upgrade"
- 58ffe141eb37 11.0 cited
-
Add basic TAP test setup for pg_upgrade
- f41e56c76e39 11.0 cited