linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Florian Weimer <fweimer@redhat.com>,
	"linux-man@vger.kernel.org" <linux-man@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	aneesh.kumar@linux.vnet.ibm.com,
	Alexander Viro <viro@zeniv.linux.org.uk>
Cc: mtk.manpages@gmail.com
Subject: Re: Naming O_TMPFILE files
Date: Mon, 26 Sep 2016 10:11:04 +0200	[thread overview]
Message-ID: <aaa0de0c-fe63-52b9-3092-ee15799323b9@gmail.com> (raw)
In-Reply-To: <2be4ffbb-abab-42c8-88a3-910230bf0d13@redhat.com>

On 09/23/2016 10:41 AM, Florian Weimer wrote:
> On 09/21/2016 01:50 PM, Florian Weimer wrote:
>> AT_EMPTY_PATH is supposed to be able to give names to files created with
>> O_TMPFILE unless O_EXCL was specified at creation time.
>>
>> However, since this commit
>>
>> commit 11a7b371b64ef39fc5fb1b6f2218eef7c4d035e3
>> Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>> Date:   Sat Jan 29 18:43:42 2011 +0530
>>
>> fs: allow AT_EMPTY_PATH in linkat(), limit that to CAP_DAC_READ_SEARCH
>>
>> linkat bails out early with AT_EMPTY_PATH and !CAP_DAC_READ_SEARCH,
>> never looking at O_EXCL.
>>
>> The /proc/self/fd kludge works for unprivileged users, but only if
>> *both* paths use AT_FDCWD.  It fails if the first path uses a real
>> descriptor for /proc/self/fd, or if the second path uses a real
>> descriptor for the current directory, or both.  For privileged users,
>> only AT_EMPTY_PATH case with an AT_FDCWD target works.
>>
>> The attached test program prints under a non-privileged user:
>>
>> error: linkat (fd, "", AT_FDCWD, out_name, AT_EMPTY_PATH):
>>   No such file or directory
>> error: linkat (fd, "", current_fd, out_name, AT_EMPTY_PATH):
>>   No such file or directory
>> success: linkat (AT_FDCWD, proc_name, AT_FDCWD, out_name,
>> AT_SYMLINK_FOLLOW)
>> error: linkat (AT_FDCWD, proc_name, current_fd, out_name,
>> AT_SYMLINK_FOLLOW):
>>   No such file or directory
>> error: linkat (proc_fd, proc_name, AT_FDCWD, out_name, AT_SYMLINK_FOLLOW):
>>   No such file or directory
>> error: linkat (proc_fd, proc_name, current_fd, out_name,
>> AT_SYMLINK_FOLLOW):
>>   No such file or directory
>> successes: 1, failures: 5
>>
>> And under a privileged user:
>>
>> success: linkat (fd, "", AT_FDCWD, out_name, AT_EMPTY_PATH)
>> error: linkat (fd, "", current_fd, out_name, AT_EMPTY_PATH):
>>   No such file or directory
>> error: linkat (AT_FDCWD, proc_name, AT_FDCWD, out_name, AT_SYMLINK_FOLLOW):
>>   No such file or directory
>> error: linkat (AT_FDCWD, proc_name, current_fd, out_name,
>> AT_SYMLINK_FOLLOW):
>>   No such file or directory
>> error: linkat (proc_fd, proc_name, AT_FDCWD, out_name, AT_SYMLINK_FOLLOW):
>>   No such file or directory
>> error: linkat (proc_fd, proc_name, current_fd, out_name,
>> AT_SYMLINK_FOLLOW):
>>   No such file or directory
>> successes: 1, failures: 5
>>
>> (Seen on tmpfs and XFS, 4.7.x kernels.)
>>
>> I double-checked with strace, and the test case does not appear to be
>> broken.  But the exhibited behavior is truly bizarre, and it means that
>> it is very difficult to give a name to an O_TMPFILE file.
> 
> The test case is broken because it does not account for the fact that an 
> O_TMPFILE file can only be linked once in this way.  This is still a bit 
> counter-intuitive, but it means that O_TMPFILE works.

Florian, could you elaborate on the "can only be linked once in 
this way"? In my experiments, it's possible to link multiple times 
to the O_TMPFILE file.

Cheers,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

  reply	other threads:[~2016-09-26  8:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-21 11:50 Naming O_TMPFILE files Florian Weimer
2016-09-23  8:41 ` Florian Weimer
2016-09-26  8:11   ` Michael Kerrisk (man-pages) [this message]
2016-09-26 15:11     ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aaa0de0c-fe63-52b9-3092-ee15799323b9@gmail.com \
    --to=mtk.manpages@gmail.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=fweimer@redhat.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).