LSM: Whiteout chardev creation sidesteps mknod hook
Subsystems (2)
Hello Christian, Paul, Mickaël and LSM maintainers!
I discovered the following bug in Landlock, which potentially also affects other LSMs:
With renameat2(2)'s RENAME_WHITEOUT flag, it is possible to create a "whiteout object" at the source of the rename. Whiteout objects are character devices with major/minor (0, 0) -- these devices are not bound to any driver, so they are harmless, but still, the creation of these files can sidestep the LANDLOCK_ACCESS_FS_MAKE_CHAR access right in Landlock.
I am unconvinced which is the right fix here -- do you have an opinion on this from the VFS/LSM side?
Option 1: Make filesystems call security_path_mknod() during RENAME_WHITEOUT?
Do it in the VFS rename hook.
* Pro: Fixes it for all LSMs
* Con: Call would have to be done in multiple filesystems
Option 2: Handle it in security_{path,inode}_rename()
Make Landlock handle it in security_inode_rename() by looking for the RENAME_WHITEOUT flag.
* Con: Operation should only be denied if the file system even implements RENAME_WHITEOUT, and we would have to maintain a list of affected filesystems for that. (That feels like solving it at the wrong layer of abstraction.)
* Con: Unclear whether other LSMs need a similar fix
Option 3: Declare that this is working as intended?
* Pro: (0, 0) is not a "real" character device
In cases 1 and 2, we'd likely need to double check that we are not breaking existing scenarios involving OverlayFS, by suddenly requiring a more lax policy for creating character devices on these directories.
Please let me know what you think. I'm specifically interested in:
1. Christian: What is the appropriate way to do this VFS wise?
2. LSM maintainers: Is this a bug that affects other LSMs as well?
Thanks,
—Günther
P.S.: For full transparency, I found this bug by pointing Google Gemini at the Landlock codebase.
Serge Hallyn
maintainerApr 7, 2026 08:05:43 Günther Noack <[email protected]>:
Quoted 30 lines
Hello Christian, Paul, Mickaël and LSM maintainers!
I discovered the following bug in Landlock, which potentially also affects other LSMs:
With renameat2(2)'s
RENAME_WHITEOUTflag, it is possible to create a "whiteout object" at the source of the rename. Whiteout objects are character devices with major/minor (0, 0) -- these devices are not bound to any driver, so they are harmless, but still, the creation of these files can sidestep theLANDLOCK_ACCESS_FS_MAKE_CHARaccess right in Landlock.I am unconvinced which is the right fix here -- do you have an opinion on this from the VFS/LSM side?
Option 1: Make filesystems call
security_path_mknod()duringRENAME_WHITEOUT?Do it in the VFS rename hook.
* Pro: Fixes it for all LSMs
* Con: Call would have to be done in multiple filesystemsOption 2: Handle it in security_{path,inode}_rename()
Make Landlock handle it in
security_inode_rename()by looking for theRENAME_WHITEOUTflag.
Quoted 8 lines
* Con: Operation should only be denied if the file system even implements
RENAME_WHITEOUT, and we would have to maintain a list of affected filesystems for that. (That feels like solving it at the wrong layer of abstraction.)
* Con: Unclear whether other LSMs need a similar fixOption 3: Declare that this is working as intended?
Option 3 has my vote.
Quoted 17 lines
* Pro: (0, 0) is not a "real" character device
In cases 1 and 2, we'd likely need to double check that we are not breaking existing scenarios involving OverlayFS, by suddenly requiring a more lax policy for creating character devices on these directories.
Please let me know what you think. I'm specifically interested in:
1. Christian: What is the appropriate way to do this VFS wise?
2. LSM maintainers: Is this a bug that affects other LSMs as well?Thanks,
—Günther
P.S.: For full transparency, I found this bug by pointing Google Gemini at the Landlock codebase.
Quoted 11 lines · Günther Noack
Hello Christian, Paul, Mickaël and LSM maintainers!
I discovered the following bug in Landlock, which potentially also affects other LSMs:
With renameat2(2)'s
RENAME_WHITEOUTflag, it is possible to create a "whiteout object" at the source of the rename. Whiteout objects are character devices with major/minor (0, 0) -- these devices are not bound to any driver, so they are harmless, but still, the creation of these files can sidestep theLANDLOCK_ACCESS_FS_MAKE_CHARaccess right in Landlock.
Any way to "write" on the filesystem should properly be controlled. The man page says that RENAME_WHITEOUT requires CAP_MKNOD, however, looking at vfs_mknod(), there is an explicit exception to not check CAP_MKNOD for whiteout devices. See commit a3c751a50fe6 ("vfs: allow unprivileged whiteout creation").
Quoted 7 lines
I am unconvinced which is the right fix here -- do you have an opinion on this from the VFS/LSM side?
Option 1: Make filesystems call
security_path_mknod()duringRENAME_WHITEOUT?
This is the right semantic.
Quoted 5 lines
Do it in the VFS rename hook.
* Pro: Fixes it for all LSMs
* Con: Call would have to be done in multiple filesystems
That would not work.
Quoted 11 lines
Option 2: Handle it in security_{path,inode}_rename()
Make Landlock handle it in
security_inode_rename()by looking for theRENAME_WHITEOUTflag.* Con: Operation should only be denied if the file system even implements
RENAME_WHITEOUT, and we would have to maintain a list of affected filesystems for that. (That feels like solving it at the wrong layer of abstraction.)
Why would we need to maintain such list? If it's only about the errno, well, that would not be perfect be ok with a proper doc.
I'm mostly worried that there might be other (future) call paths to create whiteout devices.
I think option 2 would be the most practical approach for Landlock, with a new LANDLOCK_ACCESS_FS_MAKE_WHITEOUT right.
I'm also wondering how are the chances that other kind of special file type like a whiteout device could come up in the future. Any guess Christian?
Quoted 1 line
* Con: Unclear whether other LSMs need a similar fix
I guess at least AppArmor and Tomoyo would consider that an issue.
Quoted 3 lines
Option 3: Declare that this is working as intended?
We need to be able to controle any file creation, which is not currently the case because of this whiteout exception.
Quoted 19 lines
* Pro: (0, 0) is not a "real" character device
In cases 1 and 2, we'd likely need to double check that we are not breaking existing scenarios involving OverlayFS, by suddenly requiring a more lax policy for creating character devices on these directories.
Please let me know what you think. I'm specifically interested in:
1. Christian: What is the appropriate way to do this VFS wise?
2. LSM maintainers: Is this a bug that affects other LSMs as well?Thanks,
—Günther
P.S.: For full transparency, I found this bug by pointing Google Gemini at the Landlock codebase.
CCing fsdevel and Alejandro.
Quoted 92 lines · Mickaël Salaün
Quoted 11 lines · Günther Noack
Hello Christian, Paul, Mickaël and LSM maintainers!
I discovered the following bug in Landlock, which potentially also affects other LSMs:
With renameat2(2)'s
RENAME_WHITEOUTflag, it is possible to create a "whiteout object" at the source of the rename. Whiteout objects are character devices with major/minor (0, 0) -- these devices are not bound to any driver, so they are harmless, but still, the creation of these files can sidestep theLANDLOCK_ACCESS_FS_MAKE_CHARaccess right in Landlock.Any way to "write" on the filesystem should properly be controlled. The man page says that
RENAME_WHITEOUTrequiresCAP_MKNOD, however, looking atvfs_mknod(), there is an explicit exception to not checkCAP_MKNODfor whiteout devices. See commita3c751a50fe6("vfs: allow unprivileged whiteout creation").Quoted 7 lines
I am unconvinced which is the right fix here -- do you have an opinion on this from the VFS/LSM side?
Option 1: Make filesystems call
security_path_mknod()duringRENAME_WHITEOUT?This is the right semantic.
Quoted 5 lines
Do it in the VFS rename hook.
* Pro: Fixes it for all LSMs
* Con: Call would have to be done in multiple filesystemsThat would not work.
Quoted 11 lines
Option 2: Handle it in security_{path,inode}_rename()
Make Landlock handle it in
security_inode_rename()by looking for theRENAME_WHITEOUTflag.* Con: Operation should only be denied if the file system even implements
RENAME_WHITEOUT, and we would have to maintain a list of affected filesystems for that. (That feels like solving it at the wrong layer of abstraction.)Why would we need to maintain such list? If it's only about the errno, well, that would not be perfect be ok with a proper doc.
I'm mostly worried that there might be other (future) call paths to create whiteout devices.
I think option 2 would be the most practical approach for Landlock, with a new
LANDLOCK_ACCESS_FS_MAKE_WHITEOUTright.I'm also wondering how are the chances that other kind of special file type like a whiteout device could come up in the future. Any guess Christian?
Quoted 1 line
* Con: Unclear whether other LSMs need a similar fix
I guess at least AppArmor and Tomoyo would consider that an issue.
Quoted 3 lines
Option 3: Declare that this is working as intended?
We need to be able to controle any file creation, which is not currently the case because of this whiteout exception.
Quoted 19 lines
* Pro: (0, 0) is not a "real" character device
In cases 1 and 2, we'd likely need to double check that we are not breaking existing scenarios involving OverlayFS, by suddenly requiring a more lax policy for creating character devices on these directories.
Please let me know what you think. I'm specifically interested in:
1. Christian: What is the appropriate way to do this VFS wise?
2. LSM maintainers: Is this a bug that affects other LSMs as well?Thanks,
—Günther
P.S.: For full transparency, I found this bug by pointing Google Gemini at the Landlock codebase.
Christian Brauner
maintainerQuoted 13 lines · Serge Hallyn
Apr 7, 2026 08:05:43 Günther Noack <[email protected]>:
Quoted 11 lines
Hello Christian, Paul, Mickaël and LSM maintainers!
I discovered the following bug in Landlock, which potentially also affects other LSMs:
With renameat2(2)'s
RENAME_WHITEOUTflag, it is possible to create a "whiteout object" at the source of the rename. Whiteout objects are character devices with major/minor (0, 0) -- these devices are not bound to any driver, so they are harmless, but still, the creation of these files can sidestep theLANDLOCK_ACCESS_FS_MAKE_CHARaccess right in Landlock.
They aren't devices.
Quoted 7 lines
Quoted 7 lines
I am unconvinced which is the right fix here -- do you have an opinion on this from the VFS/LSM side?
Option 1: Make filesystems call
security_path_mknod()duringRENAME_WHITEOUT?
No.
Quoted 7 lines
Quoted 7 lines
Do it in the VFS rename hook.
* Pro: Fixes it for all LSMs
* Con: Call would have to be done in multiple filesystems
Quoted 7 lines
Quoted 7 lines
Option 2: Handle it in security_{path,inode}_rename()
Make Landlock handle it in
security_inode_rename()by looking for theRENAME_WHITEOUTflag.* Con: Operation should only be denied if the file system even implements
RENAME_WHITEOUT, and we would have to maintain a list of
Why? Just deny RENAME_WHITEOUT. What does it matter if the filesystem implements it or not. Overlayfs would fall back to non-RENAME_WHITEOUT if not provided by the upper fs anway.
Quoted 8 lines
Quoted 6 lines
affected filesystems for that. (That feels like solving it at the wrong layer of abstraction.)
* Con: Unclear whether other LSMs need a similar fixOption 3: Declare that this is working as intended?
Option 3 has my vote.
Seconded.
Quoted 11 lines
Quoted 11 lines
* Pro: (0, 0) is not a "real" character device
In cases 1 and 2, we'd likely need to double check that we are not breaking existing scenarios involving OverlayFS, by suddenly requiring a more lax policy for creating character devices on these directories.
Please let me know what you think. I'm specifically interested in:
Quoted 8 lines
Quoted 8 lines
1. Christian: What is the appropriate way to do this VFS wise?
2. LSM maintainers: Is this a bug that affects other LSMs as well?Thanks,
—Günther
P.S.: For full transparency, I found this bug by pointing Google Gemini at the Landlock codebase.
Clearly.
Quoted 13 lines · Mickaël Salaün
Quoted 11 lines · Günther Noack
Hello Christian, Paul, Mickaël and LSM maintainers!
I discovered the following bug in Landlock, which potentially also affects other LSMs:
With renameat2(2)'s
RENAME_WHITEOUTflag, it is possible to create a "whiteout object" at the source of the rename. Whiteout objects are character devices with major/minor (0, 0) -- these devices are not bound to any driver, so they are harmless, but still, the creation of these files can sidestep theLANDLOCK_ACCESS_FS_MAKE_CHARaccess right in Landlock.
Quoted 5 lines
Any way to "write" on the filesystem should properly be controlled. The man page says that
RENAME_WHITEOUTrequiresCAP_MKNOD, however, looking atvfs_mknod(), there is an explicit exception to not checkCAP_MKNODfor whiteout devices. See commita3c751a50fe6("vfs: allow unprivileged whiteout creation").
Agreed, it should be possible to restrict it.
Quoted 5 lines
Quoted 5 lines
Option 2: Handle it in security_{path,inode}_rename()
Make Landlock handle it in
security_inode_rename()by looking for theRENAME_WHITEOUTflag.
Quoted 7 lines
Quoted 4 lines
* Con: Operation should only be denied if the file system even implements
RENAME_WHITEOUT, and we would have to maintain a list of affected filesystems for that. (That feels like solving it at the wrong layer of abstraction.)Why would we need to maintain such list? If it's only about the errno, well, that would not be perfect be ok with a proper doc.
Yes, it would be only about the errno. At the time of writing the initial mail, I was also worried that OverlayFS would get confused if its internal vfs_rename() call would sometimes work and sometimes be denied, but as it turns out, since OverlayFS uses its own credentials internally, this is a non-issue.
I'll send a tentative patch for option 2 for discussion.
Quoted 5 lines
I'm mostly worried that there might be other (future) call paths to create whiteout devices.
I think option 2 would be the most practical approach for Landlock, with a new
LANDLOCK_ACCESS_FS_MAKE_WHITEOUTright.
Given that this only affect immediate renameat2() calls, I would actually argue that we can probably get away with guarding this with the existing LANDLOCK_ACCESS_FS_MAKE_CHAR right?
I checked Debian code search for usages:
https://codesearch.debian.net/search?q=rename.*RENAME_WHITEOUT&literal=0
Apart from the usual proliferation of copied-around kernel headers and wrapper pass-through wrapper libraries around renameat2(), the only actual use I found for the immediate renameat2() syscall with RENAME_WHITEOUT was in fuse-overlayfs (for the exact same reason). Fuse-overlayfs is likely not running under a Landlock policy given that it doesn't have Landlock support itself and given that it also has to do a mount(), which is forbidden under Landlock, so users are also unlikely to wrap it in a Landlock domain.
Quoted 6 lines
I'm also wondering how are the chances that other kind of special file type like a whiteout device could come up in the future. Any guess Christian?
Quoted 1 line
* Con: Unclear whether other LSMs need a similar fix
Quoted 8 lines
I guess at least AppArmor and Tomoyo would consider that an issue.
Quoted 3 lines
Option 3: Declare that this is working as intended?
We need to be able to controle any file creation, which is not currently the case because of this whiteout exception.
Seconded. Landlock offers a long list of access rights to restrict the creation of new directory entries, and this is a way to create a new directory entry anyway. Even though it's not immediately clear to me how this can be abused for an actual attack, it is a violation of the previously defined Landlock policy if directory entries can be created this way.
—Günther
Quoted 8 lines · Christian Brauner
Quoted 7 lines · Serge Hallyn
Apr 7, 2026 08:05:43 Günther Noack <[email protected]>:
Quoted 5 lines
Hello Christian, Paul, Mickaël and LSM maintainers!
I discovered the following bug in Landlock, which potentially also affects other LSMs:
Quoted 8 lines
Quoted 6 lines
Quoted 6 lines
With renameat2(2)'s
RENAME_WHITEOUTflag, it is possible to create a "whiteout object" at the source of the rename. Whiteout objects are character devices with major/minor (0, 0) -- these devices are not bound to any driver, so they are harmless, but still, the creation of these files can sidestep theLANDLOCK_ACCESS_FS_MAKE_CHARaccess right in Landlock.They aren't devices.
The LANDLOCK_ACCESS_FS_MAKE_CHAR access right is about the *creation of character device directory entries*.
These files do not hook up to any of the kernel's device driver subsystems, but they *are* directory entries of the chardev type, and the creation of these is still sidestepping the LANDLOCK_ACCESS_FS_MAKE_CHAR right.
Quoted 20 lines
Quoted 5 lines
Quoted 5 lines
I am unconvinced which is the right fix here -- do you have an opinion on this from the VFS/LSM side?
Option 1: Make filesystems call
security_path_mknod()duringRENAME_WHITEOUT?No.
Quoted 12 lines
Quoted 12 lines
Do it in the VFS rename hook.
* Pro: Fixes it for all LSMs
* Con: Call would have to be done in multiple filesystemsOption 2: Handle it in security_{path,inode}_rename()
Make Landlock handle it in
security_inode_rename()by looking for theRENAME_WHITEOUTflag.
Quoted 6 lines
Quoted 2 lines
Quoted 2 lines
* Con: Operation should only be denied if the file system even implements
RENAME_WHITEOUT, and we would have to maintain a list ofWhy? Just deny
RENAME_WHITEOUT. What does it matter if the filesystem implements it or not. Overlayfs would fall back to non-RENAME_WHITEOUT if not provided by the upper fs anway.
I'll send a patch with this approach for discussion.
It turns out it is less difficult than I feared:
* OverlayFS uses its own credentials object, and since that is not under a Landlock policy, the OverlayFS-internal vfs_rename() invocations do not have that problem. (Under a Landlock policy, mount(2) is not permitted, so the OverlayFS-internal credentials are not Landlocked.)
* The remaining use case is only when a user calls renameat2(..., RENAME_WHITEOUT) directly on a filesystem (which is not necessarily part of an OverlayFS). That case can be restricted with Landlock.
We might have slight error code inconsistencies yes, but as Mickaël is saying on the sibling mail thread, it would not be worth the tradeoff to maintain a list of supported file systems just to get the error codes right.
Quoted 10 lines
Quoted 8 lines
Quoted 6 lines
affected filesystems for that. (That feels like solving it at the wrong layer of abstraction.)
* Con: Unclear whether other LSMs need a similar fixOption 3: Declare that this is working as intended?
Option 3 has my vote.
Seconded.
(See also discussion on sibling thread)
I also don't currently see how an attacker would abuse this, but I still see this as a violation of Landlock's security model if we can create a policy that denies the creation of character device directory entries, and then we still have a way to make them appear there where we previously had a different file.
I'll send a tentative patch for option 2 for discussion. We can discuss more in the context of that more concrete proposal, if needed.
—Günther
Quoted 4 lines · Günther Noack
I also don't currently see how an attacker would abuse this, but I still see this as a violation of Landlock's security model if we can create a policy that denies the creation of character device directory entries, and then we still have a way to make them appear there where we previously had a different file.
Look: a whiteout is a whiteout, NOT a character device. Don't let the fact that it's represented by "c 0 0" fool you, this is a completely different beast. See commit a3c751a50fe6 ("vfs: allow unprivileged whiteout creation").
Does this beast need special handling by LSMs? I have no idea, but treating them the same as char devs sounds like a bad idea.
Thanks,
Miklos
Quoted 6 lines · Miklos Szeredi
Quoted 4 lines · Günther Noack
I also don't currently see how an attacker would abuse this, but I still see this as a violation of Landlock's security model if we can create a policy that denies the creation of character device directory entries, and then we still have a way to make them appear there where we previously had a different file.
Quoted 7 lines
Look: a whiteout is a whiteout, NOT a character device. Don't let the fact that it's represented by "c 0 0" fool you, this is a completely different beast. See commit
a3c751a50fe6("vfs: allow unprivileged whiteout creation").Does this beast need special handling by LSMs? I have no idea, but treating them the same as char devs sounds like a bad idea.
Thanks for the pointer to that commit. I was under the impression that creation of the whiteout objects required CAP_MKNOD, but it seems you have dropped that requirement in that commit.
(FWIW, I was mislead by the rename(2) man page[1], which is apparently not up to date and where it explicitly says:
RENAME_WHITEOUT requires the same privileges as creating a device node (i.e., the CAP_MKNOD capability).
So with that assumption, it seemed natural that this should have extended equivalently into a Landlock policy.)
So if the "c 0 0" whiteout device is indeed a different kind of file, maybe we would need to treat it with a separate Landlock access right after all then. I'll ponder it.
FWIW, besides introducing a new LANDLOCK_ACCESS_FS_MAKE_WHITEOUT access right and adding more special cases to the Landlock API, another possible option might be to just forbid creating whiteout objects altogether, when under a Landlock policy. As the man page also notes, "This operation makes sense only for overlay/union filesystem implementations", and since these likely can't use Landlock anyway due to mounting, I think there would be no use case left where anyone would want to perform such an operation within a Landlock domain -- I don't think this would break anyone. Mickaël, do you have an opinion on that idea?
—Günther
P.S. Initial patch set from Saturday is at [2], but this still uses the LANDLOCK_ACCESS_FS_MAKE_CHAR right.
[1] https://man7.org/linux/man-pages/man2/rename.2.html
[2] https://lore.kernel.org/all/[email protected]/
Quoted 33 lines · Günther Noack
Quoted 6 lines · Miklos Szeredi
Quoted 4 lines · Günther Noack
I also don't currently see how an attacker would abuse this, but I still see this as a violation of Landlock's security model if we can create a policy that denies the creation of character device directory entries, and then we still have a way to make them appear there where we previously had a different file.
Quoted 7 lines
Look: a whiteout is a whiteout, NOT a character device. Don't let the fact that it's represented by "c 0 0" fool you, this is a completely different beast. See commit
a3c751a50fe6("vfs: allow unprivileged whiteout creation").Does this beast need special handling by LSMs? I have no idea, but treating them the same as char devs sounds like a bad idea.
Thanks for the pointer to that commit. I was under the impression that creation of the whiteout objects required
CAP_MKNOD, but it seems you have dropped that requirement in that commit.(FWIW, I was mislead by the rename(2) man page[1], which is apparently not up to date and where it explicitly says:
RENAME_WHITEOUTrequires the same privileges as creating a device node (i.e., theCAP_MKNODcapability).So with that assumption, it seemed natural that this should have extended equivalently into a Landlock policy.)
So if the "c 0 0" whiteout device is indeed a different kind of file, maybe we would need to treat it with a separate Landlock access right after all then. I'll ponder it.
Quoted 10 lines
FWIW, besides introducing a new
LANDLOCK_ACCESS_FS_MAKE_WHITEOUTaccess right and adding more special cases to the Landlock API, another possible option might be to just forbid creating whiteout objects altogether, when under a Landlock policy. As the man page also notes, "This operation makes sense only for overlay/union filesystem implementations", and since these likely can't use Landlock anyway due to mounting, I think there would be no use case left where anyone would want to perform such an operation within a Landlock domain -- I don't think this would break anyone. Mickaël, do you have an opinion on that idea?
Just as a point of comparison, for SELinux, I see the following permission checks occur upon renameat2(..., RENAME_WHITEOUT):
1. add_name, write, and search permissions to the destination dir
2. rename permission to the source file
3. if the dst file already exists, unlink permission to the dst file
4. remove_name, write, and search permissions to the source dir
And the following permission checks upon mknod(..., S_IFCHR, 0):
1. add_name, write, and search permissions to the destination dir
2. create permission to the new chr_file
So we are missing the create check for the whiteout file on renameat2(); not sure if that's working as intended or a bug.
Quoted 8 lines
—Günther
P.S. Initial patch set from Saturday is at [2], but this still uses theLANDLOCK_ACCESS_FS_MAKE_CHARright.[1] https://man7.org/linux/man-pages/man2/rename.2.html
[2] https://lore.kernel.org/all/[email protected]/
Quoted 19 lines · Günther Noack
Quoted 6 lines · Miklos Szeredi
Quoted 4 lines · Günther Noack
I also don't currently see how an attacker would abuse this, but I still see this as a violation of Landlock's security model if we can create a policy that denies the creation of character device directory entries, and then we still have a way to make them appear there where we previously had a different file.
Quoted 7 lines
Look: a whiteout is a whiteout, NOT a character device. Don't let the fact that it's represented by "c 0 0" fool you, this is a completely different beast. See commit
a3c751a50fe6("vfs: allow unprivileged whiteout creation").Does this beast need special handling by LSMs? I have no idea, but treating them the same as char devs sounds like a bad idea.
Thanks for the pointer to that commit. I was under the impression that creation of the whiteout objects required
CAP_MKNOD, but it seems you have dropped that requirement in that commit.
Quoted 8 lines
(FWIW, I was mislead by the rename(2) man page[1], which is apparently not up to date and where it explicitly says:
RENAME_WHITEOUTrequires the same privileges as creating a device node (i.e., theCAP_MKNODcapability).So with that assumption, it seemed natural that this should have extended equivalently into a Landlock policy.)
I agree with Miklos and also pointed out to this commit:
https://lore.kernel.org/all/[email protected]/
Quoted 4 lines
So if the "c 0 0" whiteout device is indeed a different kind of file, maybe we would need to treat it with a separate Landlock access right after all then. I'll ponder it.
What is sure is that we should not treat it like character devices, which required special capabilities/permissions because they are a door to a driver interface.
Quoted 6 lines
FWIW, besides introducing a new
LANDLOCK_ACCESS_FS_MAKE_WHITEOUTaccess right and adding more special cases to the Landlock API,another possible option might be to just forbid creating whiteout objects altogether, when under a Landlock policy.
This doesn't feel right. Mount operations restriction are there because Landlock currently cannot properly control mount operations yet (see
https://github.com/landlock-lsm/linux/issues/14).
Quoted 3 lines
As the man page
also notes, "This operation makes sense only for overlay/union filesystem implementations",
The man pages contain at least one important error wrt this feature, so we should only trust the kernel code. Anyway, anyone can create a whiteout with mknod, so let's consider that there are other use cases.
Quoted 5 lines
and since these likely can't use Landlock
anyway due to mounting, I think there would be no use case left where anyone would want to perform such an operation within a Landlock domain -- I don't think this would break anyone. Mickaël, do you have an opinion on that idea?
The LANDLOCK_ACCESS_FS_MAKE_WHITEOUT right makes sense wrt other MAKE_* rights (i.e. per file type). See may detailed reply here:
https://lore.kernel.org/r/[email protected]
BTW, I don't understand why only the renameat2(2) syscall can (indirectly) create this file type; why not also unlink(2) or rmdir(2)?
Quoted 9 lines
—Günther
P.S. Initial patch set from Saturday is at [2], but this still uses theLANDLOCK_ACCESS_FS_MAKE_CHARright.[1] https://man7.org/linux/man-pages/man2/rename.2.html
[2] https://lore.kernel.org/all/[email protected]/
Quoted 2 lines · Mickaël Salaün
BTW, I don't understand why only the renameat2(2) syscall can (indirectly) create this file type; why not also unlink(2) or rmdir(2)?
The reason is that the same effect is possible with first creating the whiteout in the work directory with mknod, then renaming it over the target. Since the work directory is needed anyway, this spares filesystems from having to implement yet another overlayfs specific operation.
Thanks,
Miklos