"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Omar Polo <op@omarpolo.com>
Subject:
Re: attempt at respecting umask
To:
Stefan Sperling <stsp@stsp.name>
Cc:
gameoftrees@openbsd.org
Date:
Sat, 29 Oct 2022 16:47:01 +0200

Download raw body.

Thread
On 2022/10/29 16:25:57 +0200, Stefan Sperling <stsp@stsp.name> wrote:
> I have one remining question:
> How does the umask preservation interact with versioning of executable-bits?

At the moment the umask wins, for any bit.

I haven't tried but expect various breakages when running with an
umask that has the user-bits set and I don't think there's much we
can do.

> An "easy" way to deal with the intersection of both features might be to
> ignore the umask as far as x-bits are concerned. Meaning if the umask filters
> out x-bits, but the tree entry's mode has an x-bit set, then set x-bits in
> the filesystem regardless of what the umask says. This way, we require users
> to clear x-bits explicitly if they want to get rid of them, rather than
> letting the umask clear versioned x-bits implicitly.

Yep, we could amend apply_umask so it clears the x-bits (or the
whole user part) from the current umask.  But it's not enough.
mkdir(2) follows umask too for example and can break if someone
runs with umask that clears the x-bit:

	% umask 177
	% mkdir foo
	% ls -ld foo
	drw-------  2 op  wheel   512B Oct 29 16:38 foo/
	% cd foo
	ksh: cd: foo: bad directory

woops.

I'm not sure what to do, but I'd tend (maybe for lazyness) to ignore
the problem, I assume that whoever sets the higher umask bits knows
what they're doing.