Date: Wed, 13 Apr 2016 17:03:20 +0100
From: "Richard W.M. Jones" <rjones@redhat.com>
To: Colin Walters <walters@verbum.org>
Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com,
        hpa@zytor.com, akpm@linux-foundation.org, luto@kernel.org,
        viro@zeniv.linux.org.uk, mathieu.desnoyers@efficios.com,
        zab@redhat.com, emunson@akamai.com, paulmck@linux.vnet.ibm.com,
        aarcange@redhat.com, josh@joshtriplett.org, xemul@parallels.com,
        sfr@canb.auug.org.au, milosz@adfin.com, rostedt@goodmis.org,
        arnd@arndb.de, ebiederm@xmission.com, gorcunov@openvz.org,
        iulia.manda21@gmail.com, dave.hansen@linux.intel.com,
        mguzik@redhat.com, adobriyan@gmail.com, dave@stgolabs.net,
        linux-api@vger.kernel.org, gorcunov@gmail.com, fw@deneb.enyo.de
Subject: Re: [PATCH v2 0/2] vfs: Define new syscall getumask.
Message-ID: <20160413160320.GI11600@redhat.com>
References: <1460552272-15985-1-git-send-email-rjones@redhat.com>
 <1460562105.353100.577697153.013DF466@webmail.messagingengine.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1460562105.353100.577697153.013DF466@webmail.messagingengine.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2259
Lines: 54

On Wed, Apr 13, 2016 at 11:41:45AM -0400, Colin Walters wrote:
> On Wed, Apr 13, 2016, at 08:57 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.
> 
> I assume you just want to do this from a shared library so you can
> determine whether or not you need to call fchown() after making files
> and the like?  If that's the case it'd be good to note it in the commit
> message.

Yes, the use case is something like that.  I write a shared library
(libguestfs) and we get bug reports that turn out to be caused by odd
umask settings.  Of course we fix these on a case-by-case basis, but
we also want to include the current umask in debug output so that we
can identify the problem quickly in future reports.

Actually I wrote a rather involved getumask substitute:

  https://github.com/libguestfs/libguestfs/blob/master/src/launch.c#L477

It works by creating a temporary directory, writing a file inside that
directory with mode 0777, then calling fstat(2) to work out what mode
the kernel gave it.

It turns out this code is not even correct.  It was pointed out to me
that there is a filesystem umask mount option (and fmask, dmask too)
which stops this from working properly.

So it's a lot of work to read umask safely inside a shared library.

I will update the commit comment with a brief summary of the above.

> BTW...it might be a good idea to add a flags argument:
> https://lwn.net/Articles/585415/
>
> Did you consider calling this `umask2`, having the initial version
> only support retrieving it via a UMASK_GET flag, and lay the
> groundwork to support setting a threadsafe umask with a
> UMASK_SET_THREAD flag?

Can certainly do it like this if that is preferable.

For my needs, getumask as implemented now is sufficient.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/