A client of mine discovered that he needs to include 'crossmnt' along with his NFS export options. I am going to write the option into our software, so that he doesn't have to put in a hack and can use crossmnt as a real option.
Is this a correct explanation of crossmnt that I can use in our docs?
Crossmnt allows the NFS client to traverse the directories below the exported root. For example:
etc/exports:
/exports *(fsid=0,ro,root_squash,sync)
/exports/doc *(ro,root_squash,bind=/usr/share/doc)
With crossmnt, the client can see the contents of /exports/doc as the subfolder of /exports, while without crossmnt, doc would appear to be an empty folder.
This video was used for an example:
https://www.youtube.com/watch?v=-9cJciX8dB8
Does that sound right? Thank you.
I believe that there is something missing in this explanation.. what i know from crossmount is that it allows you to see a mounting point inside an exported directory. If the exported directory doesn't have any partition mounted over its subfolders, they should be visible in the client side of the NFS.
For example, if you have an exported directory over "/mnt/testing_dir", with this content:
/mnt/testing_dir/
dir1/
text1.txt
executable.bin
dir2/ (mount point for /dev/sda6)
doc1
doc2
The "dir1" will be visible even if without the "crossmnt" option. However, "dir2", as it is a mounting point, will be visible with the "crossmnt" option, and will be empty without it (unless you use another options like "nohide").
Reference:
crossmnt -
This option is similar to nohide but it makes it possible for clients to move from the filesystem marked with crossmnt to exported filesystems mounted on it. Thus when a child filesystem "B" is mounted on a parent "A", setting crossmnt on "A" has the same effect as setting "nohide" on B.
Related
I'm working on an unfamiliar codebase which includes some components, <v-content>, <v-card> etc.
Is there a reliable way to determine where they are defined? (Obviously I can google this particular example - I'm looking for a general technique for mapping a component name back to its definition.)
I'm assuming you're referring to global components, as local component registration requires explicitly importing the component from a particular source directory or module, in which case the source of the component would be obvious.
Global component registration syntax is:
Vue.component('componentName', ...)
Therefore, you could search your source directory (including node_modules) for that sequence. For example, you could grep it with:
grep -nr Vue\\.component .
I have a working VueJs application, and when a user logs in, he gets some rights from the server like administrator, readOnlyUser, worker etc. Based on these privileges, some components/functionality in the application should be or, should not be available to the user. For an example I would like to put a reference to an access-right method on my differenct components/divs:
<MyComponent v-if="hasRights()"></MyComponent>
Or just access this method from the script section.
I am thinking of using mixins, this seem to suit my needs, but is mixin´s the right way to solve this issue? Are there another more patten-like correct way to do it?
My recommendation for architecture:
Create files per rights:
Admin.js
User1.js
User2.js
etc.
Now you can create a function (wherever that takes in the user from your server, and then referes you to the right file. By doing this you can call in . your components: this.$config.get().displaySomething . Where the get() knows which file to go to. Make your config available on bootstrap.
The reason I don't recommend vuex is since it sounds like your config is static and can just be hard coded into file.
I studied the documentation for automatic global generation of base components but it is confusing. Can anyone please explain it in detail?
You can use require.context() in order to resolve a directory where components live during webpack's build process. this exposes to you, within the browser, the list of files in that directory. From that, you can use some magic to automatically register them, here's an example:
const files = require.context('./components', true, /\.vue$/i);
files.keys().map(key => Vue.component(key.split('/').pop().split('.')[0], files(key).default));
So in the above, we've said that we want webpack to create a context for us of all files in the './components' directory. From there, we can loop over all the keys of the files (which represent the file name) and register them with Vue.component(...)
I recommend watching this video:
https://www.vuemastery.com/courses/real-world-vue-js/global-components
First you can understand why you may want to use global components, then why you would want to automatically global register those components, and then what the registration code (taken from the following link) actually does.
https://v2.vuejs.org/v2/guide/components-registration.html#Automatic-Global-Registration-of-Base-Components
I built a virtual filesystem (not a namespace extension) for Windows which acts as a frontend of our document management server consisting of files and folders. In order to be able to display some metadata of the DMS objects in Windows Explorer as additional selectable columns, I successfully provided properties to the Windows Property System by implementing a COM Property Handler. Wheras normal property handlers focus on specific file types for which they feel responsible, my Property Handler adds properties to all files regardless of their type. Because Property Handlers can only be registered on the file type level, I registered my handler for about 30 types under
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\PropertySystem\PropertyHandlers\<.Extension>
However, I did not manage to register the Property Handler for folder objects. Since all objects in our file system are virtual I build the property store (IPropertyStore) by implementing IInitializeWithFile instead of IInitializeWithStream. The properties are requested from our DMS with the path of IInitializeWithFile acting as key and were not read from an objects content. This concept would work for folders as well.
For getting called on folders I tried to associate the handler by registering under different well known identifiers like Folder, Directory, AllFileSystemObjects and * instead of the file extension without success.
I also didn’t find anything in the MSDN documentation regarding this aspect.
Is there a way to register a Windows Property Handler on folders? Or is there some other way to add custom columns to folders in Windows Explorer?
I'm not sure if it is possible to do this.
Property handlers are clearly not the right approach, they are system wide and there can only be one per file extension. They should only be implemented by the software that "owns" the file extension and can parse the file to extract properties.
The old column handlers would have been your best bet (IMHO) but they are officially dead and you already said you can't use them.
Have you considered creating a namespace extension? Either as a root item somewhere (Desktop or My Computer) the way My Documents used to work in 2000/XP or maybe something more along the lines of how OneDrive works?
I'm not sure if desktop.ini files work in the root of a drive but it might be worth looking into. You would then find yourself in the poorly documented land of [.ShellClassInfo] and its CLSID, CLSID2 and UICLSID members. The general idea would be to act as a IShellFolder proxy on top of the "real" IShellFolder so you could create a multiplex property store. I think there are some (undocumented?) property keys you can override to change the folders default columns and tooltips as well.
There is also something called a delegated folder that allows you to play with nested PIDLs but the documentation is once again pretty useless so I'm not sure if this is something worth looking into.
A 3rd option is to pretend to be a cloud storage provider. I don't know if this gets you any closer to your goal and you would still have to implement some NSE bits to get to the point where you can layer yourself on top of the underlying IShellFolder. This feature is rather new and only documented to work on Windows 10.
The inner workings of how Explorer/IShellBrowser is connected to the IShellFolder/IShellView is one of the least documented parts of Windows. There are hundreds of undocumented interfaces. Explorer gives DefView special treatment leaving other 3rd-party implementations out in the cold.
My feeling is that there is no clean solution to implement this on top of a drive letter but you might get lucky, if Raymond Chen drops by he might have some tips for you...
I am going to check loading and memory path of process to find malicious processes. for example if csrss.exe is executed from other path than Windows\System32 would be considered malicious. But the result of Volatility for common process such as csrss.exe is as follows:
loading path : \??\C:\WINDOWS\system32\csrss.exe
mapped path : \WINDOWS\system32\csrss.exe
or for smss.exe I have
loading path : \SystemRoot\System32\smss.exe
mapped path : \WINDOWS\system32\smss.exe
So are these two paths equal in these two examples or not ? I.e. is \??\C:\WINDOWS == \WINDOWS
or \SystemRoot\System32 == \WINDOWS\system32
No, a ??\C:\... without the leading \ is not valid, to the best of my knowledge. Perhaps some libraries will accept this as input, however, and convert it appropriately. Or perhaps you missed some bits from the paths you copied and pasted?
Either way we'll stick to the (NT flavored) Windows behavior.
However, \??\C:\... definitely is. You can find a comprehensive discussion here and the official documentation here. Some of the aspects we need to know are also explained here.
Some implementation details
Quoting from the Google Project Zero page above:
There are 7 types of path that the Win32 API distinguishes between,
and potentially does different things with. NTDLL has a function,
RtlDetermineDosPathNameType_U, which, given a Unicode string will
return you the path type. We’ll go through each one of these types in
the next section. The following prototype can be used to call this
function:
enum RTL_PATH_TYPE {
RtlPathTypeUnknown,
RtlPathTypeUncAbsolute,
RtlPathTypeDriveAbsolute,
RtlPathTypeDriveRelative,
RtlPathTypeRooted,
RtlPathTypeRelative,
RtlPathTypeLocalDevice,
RtlPathTypeRootLocalDevice
};
RTL_PATH_TYPE NTAPI RtlDetermineDosPathNameType_U(_In_ PCWSTR Path);
To follow along, download WinObj from Sysinternals/Microsoft and start it elevated (right-click + "Run as Administrator").
Potentially valid paths you may see
You have a number of path representations (as discussed in-depth in the linked articles). Let's consider the path C:\Windows\System32\csrss.exe you gave:
Win32 path: C:\Windows\System32\csrss.exe (\Windows\System32\csrss.exe would be a variation that depends on the current directory at the time the path is processed, if it is somewhere on C: they should be identical)
NT native path:
\??\C:\Windows\System32\csrss.exe
\GLOBAL??\C:\Windows\System32\csrss.exe
\SystemRoot\System32\csrss.exe
Local device path: \\.\C:\Windows\System32\csrss.exe
Root local device path: \\?\C:\Windows\System32\csrss.exe
DOS paths: this is relevant for all paths whose individual path segments are longer than the classic 8.3 DOS path name segments. If configured, a 8.3 DOS name will be generated (usually something in the form of C:\LongPathName -> C:\LONGPA~1) ... this may be important for forensic purposes (you quote volatility), but is mostly legacy behavior.
UNC paths also exist and in fact a local device path (\\.\...) looks like a UNC path with server name . which could even be a thing, considering . is the current directory further down in paths, so why not the current machine up top? Either way, go read the articles if you want to know about those in more detail.
Starting at the top, drilling down
C:\Windows\System32\csrss.exe when passed to an API like CreateFile will be converted to \??\C:\Windows\System32\csrss.exe which the object manager then takes in for processing.
If a relative path was given, there will be additionally processing to convert to a full path, basically.
\\.\C:\Windows\System32\csrss.exe when passed to an API like CreateFile will be "converted" to \??\C:\Windows\System32\csrss.exe after some processing. Just like without the \\.\ prefix some additional processing happens before this path is passed down to the object manager.
\\?\C:\Windows\System32\csrss.exe when passed to an API like CreateFile will be "converted" to \??\C:\Windows\System32\csrss.exe. No further processing happens at the Win32 level. This is basically an escape route straight to the object manager (and in the Fun facts section I'll share a related fun fact).
The object manager view
Receiving a path like \??\C:\Windows\System32\csrss.exe the object manager attempts to find \?? first.
\?? used to be an actual item, these days it is a "view" of \GLOBAL?? overlaid with your session-specific DosDevices.
An example of session-specific DosDevices would be mapped network shares.
For a drive letter F: mapped to \\fileserver\Share
Under the hood you will have a session-specific DosDevices object directory like \Sessions\0\DosDevices\00000000-00261e8a which would contain a symbolic link named F:, pointing to \Device\LanmanRedirector\;F:0000000000261e8a\fileserver\Share ... or similar.
So in essence when looking up names in \?? the object manager will look in your session specific DosDevices, followed by \GLOBAL?? (or was it the other way around? 🤔)
Another example would be VeraCrypt mounted volumes. For example your drive letter T: may map to \Device\VeraCryptVolumeT
Having figured out that C: is \GLOBAL??\C: in our case, the object manager checks what C: is. On my Windows 10 it figures out that this is a symbolic link pointing to \Device\HarddiskVolume3.
Having found the device (and implicitly the driver associated with it) the object manager now will pass the remainder of the path (\Windows\System32\csrss.exe) to the device \Device\HarddiskVolume3, whose driver will hopefully do the right thing, create a file object and so on ...
And now that you know this you can follow along on your system for arbitrary paths.
What about \SystemRoot?
Well, on modern Windows versions the behavior differs a little from how it used to be, but \SystemRoot is a symbolic link resolving to the Windows directory on all NT-based Windows versions I am aware of. The Win32 subsystem parrots this in the %SystemRoot% environment variable (albeit in Win32 path notation).
On my Windows 10 \SystemRoot is a symbolic link to \Device\BootDevice\windows and so the path to a driver (which is the typical use case in the registry) can be expressed much more easily for early boot drivers (less processing needed by the object manager).
As a side note: on my system - as you'd expect - \Device\BootDevice maps to \Device\HarddiskVolume3.
Fun facts
The DosDevices object directory cited in the Google Project Zero article is no longer a thing. These days it's a symbolic link to \?? (not \GLOBAL??).
The subst command line utility allows you to create symbolic links inside your session-specific DosDevices object directory to map some directory path to a drive letter (under the hood uses DefineDosDevice()).
Files are unnamed objects, that is they have no name that could be directly processed by the NT object manager. Instead the remainder of a file name - after reparsing etc - will be passed to the driver responsible for the device object representing the file system volume (i.e. partition). That driver then takes care of making sense of the name.
\REGISTRY\MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem (while this doesn't name a file, it is a perfectly valid native path to what you would see as HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
That escape routes named \??\ and \\?\
I mentioned before that the prefix \??\ is an escape route. Consider a file/folder path with a trailing dot, something you will not be able to create or access ordinarily from the Win32 subsystem. Similarly the reserved DOS device names (e.g. NUL, COM1 etc.) cannot be created or manipulated ordinarily.
Little experiment ...
start cmd.exe (Win+R)
go to your desktop folder: cd /d "%USERPROFILE%\Desktop"
Now create a new file test.txt. (note the trailing dot): echo . > \??\%CD%\test.txt. (the %CD% refers to the current directory)
Use Windows Explorer to navigate to your desktop folder. Try to open the file test.txt. by double-clicking. Pick Notepad when it asks you what program to use to open it.
You should see:
... please note the path (without trailing dot).
Now try to delete the file from Windows Explorer. It won't work.
NB: Some alternative file managers like Far or Speed Commander won't have trouble with this!
Now switch back to the command line window and use del /f \\?\%CD%\test.txt.
Did you notice something? I sneakily changed from \??\ to \\?\ because apparently the implementation of del doesn't like the former.
Depending on the implementation of your specific program it can vary whether \??\ or \\?\ is successful.
Another experiment would be to create reserved names like NUL or COM1 or tinker with WSL2's per-directory case-sensitivity.
Note
Win32 may sound outdated, but the Win32 subsystem and the respective "Windows personality" implemented through csrss.exe and its subsystem DLLs (kernel32.dll and friends) was called just that. Besides, if you're picky it may bother you particularly to find out that all the native 64-bit binaries on a modern x64 Windows reside in %SystemRoot%\System32 (<- yes, that's a 32 right there 😁). Enjoy!
Further reading
In addition to the articles from the top, I can recommend these books:
Obviously the Windows Internals book series.
Windows System Programming by Pavel Yosifovich also has some details