On Thu, Apr 14, 2016 at 4:08 AM, Richard W.M. Jones wrote:
> It's not possible to read the process umask without also modifying it,
> which is what umask(2) does. A library cannot read umask safely,
> especially if the main program might be multithreaded.
>
> Add a new status
On Fri, Apr 15, 2016 at 02:29:52PM +0100, Richard W.M. Jones wrote:
>
> The use case is that we have endless trouble with people setting weird
> umask() values (usually on the grounds of "security"), and then
> everything breaking. I'm on the hook to fix these. We'd like to add
> debugging to
On Thu, Apr 14, 2016 at 2:08 PM, Richard W.M. Jones wrote:
> It's not possible to read the process umask without also modifying it,
> which is what umask(2) does. A library cannot read umask safely,
> especially if the main program might be multithreaded.
>
> Add a new status
It's not possible to read the process umask without also modifying it,
which is what umask(2) does. A library cannot read umask safely,
especially if the main program might be multithreaded.
Add a new status line ("Umask") in /proc//status. It contains
the file mode creation mask (umask) in
v1 -> v2:
- Change printf format to %#04o.
- Retest and update examples accordingly.
--
It's not possible to read the process umask without also modifying it,
which is what umask(2) does. A library cannot read umask safely,
especially if the main program might be multithreaded.
Add