Global whiteouts are unreliable for dynamically recreated VPN interfaces

[soranerai]

Environment

• NoMount commit: 5e26349
• Kernel: 6.1.157-android14
• Main-profile UID: 10468
• Work-profile UID: 1210468
• Work profile: user 12

Configuration

The following rules are global. nm uid list is empty.

/proc/sys/net/ipv6/neigh/tun0
/proc/net/dev_snmp6/tun0
/sys/class/net/tun0
/proc/sys/net/ipv6/conf/tun0
/proc/sys/net/ipv4/conf/tun0
/proc/sys/net/ipv4/neigh/tun0

They were added using nm rule add --whiteout.

Steps to reproduce

1. Start the VPN and create tun0.
2. Add the global whiteout rules listed above.
3. Check the paths from the main and work profiles.
4. Stop and restart the VPN so that tun0 is destroyed and recreated.
5. Add the global whiteout rules listed above.
6. Check the same paths again.

Expected behavior

Global whiteout rules should hide the recreated tun0 entries consistently from both profiles.

Actual behavior

The result depends on the lifecycle of tun0 and the state of the procfs dentries.

Before restarting the VPN, several /proc entries remained visible despite the active whiteout rules. After restarting the VPN, most of them became hidden, but the behavior was still inconsistent.
For example:

• ABSENT: /proc/sys/net/ipv4/neigh/tun0
• PRESENT: /proc/net/dev_snmp6/tun0

The same behavior was observed without configuring any UID exclusions, so this does not appear to be related to UIDs above 10000.

The affected paths are dynamically generated procfs and network-interface entries. The equivalent /sys/class/net/tun0 whiteout behaves more consistently.

Additional information

/proc/net resolves through /proc/self/net, and the main and work-profile processes use different mount namespaces. This may be relevant, but the exact cause is not yet confirmed.

SUSFS add_sus_path_loop works fine.

[soranerai]

Here is the code I use to interact with nomount and susfs (just search for the keywords).

https://github.com/soranerai/vpnhide_next_backend/tree/main/daemon