procfs/d_invalidate break userland

procfs/d_invalidate break userland

[Mickaël Salaün]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

Hi,

For your information, the commit bbd5192412fdedbae00888316bfe350bf89d0458 (proc: Update proc_flush_task_mnt to use d_invalidate), in the v3.17, break some userland use of procfs.

In a user namespace, I'm using /proc/<pid>/task/<tid>/fdinfo to mount a tmpfs, chdir into it, terminate the <tid> thread, and use the tmpfs as a private working directory for PID 1. This trick is useful to disconnect/d_drop a directory from the current file system and make it inaccessible to the other processes (kind of an O_TMPFILE for directory).

With the v3.17 this is no more possible because it's no more possible to mount anything in this tmpfs nor use the previously mounted file systems in this tmpfs.

The new d_invalidate is really good to lazily invalidate/umount an entire hierarchy but I'm not sure the intention was to remove this useful "feature" ;)

 Mickaël



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: procfs/d_invalidate break userland

[Al Viro]

On Thu, Apr 23, 2015 at 01:41:02AM +0200, Mickaël Salaün wrote:
> Hi,
> 
> For your information, the commit bbd5192412fdedbae00888316bfe350bf89d0458 (proc: Update proc_flush_task_mnt to use d_invalidate), in the v3.17, break some userland use of procfs.
> 
> In a user namespace, I'm using /proc/<pid>/task/<tid>/fdinfo to mount a tmpfs, chdir into it, terminate the <tid> thread, and use the tmpfs as a private working directory for PID 1. This trick is useful to disconnect/d_drop a directory from the current file system and make it inaccessible to the other processes (kind of an O_TMPFILE for directory).
> 
> With the v3.17 this is no more possible because it's no more possible to mount anything in this tmpfs nor use the previously mounted file systems in this tmpfs.
> 
> The new d_invalidate is really good to lazily invalidate/umount an entire hierarchy but I'm not sure the intention was to remove this useful "feature" ;)

And what will happen if you mount stuff there and exit?  Dirty filesystem
after reboot?
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: procfs/d_invalidate break userland

[Mickaël Salaün]

[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]


On 04/23/2015 01:51 AM, Al Viro wrote:
> On Thu, Apr 23, 2015 at 01:41:02AM +0200, Mickaël Salaün wrote:
>> Hi,
>>
>> For your information, the commit bbd5192412fdedbae00888316bfe350bf89d0458 (proc: Update proc_flush_task_mnt to use d_invalidate), in the v3.17, break some userland use of procfs.
>>
>> In a user namespace, I'm using /proc/<pid>/task/<tid>/fdinfo to mount a tmpfs, chdir into it, terminate the <tid> thread, and use the tmpfs as a private working directory for PID 1. This trick is useful to disconnect/d_drop a directory from the current file system and make it inaccessible to the other processes (kind of an O_TMPFILE for directory).
>>
>> With the v3.17 this is no more possible because it's no more possible to mount anything in this tmpfs nor use the previously mounted file systems in this tmpfs.
>>
>> The new d_invalidate is really good to lazily invalidate/umount an entire hierarchy but I'm not sure the intention was to remove this useful "feature" ;)
> 
> And what will happen if you mount stuff there and exit?  Dirty filesystem
> after reboot?
> 

I didn't notice any but only do tmpfs or bind mounts because of user namespace anyway.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]