I'm not much of a Perl developer but I need it to make triggers for perforce.
So this is the background:
I have a windows service that runs as admin that calls the Perl script on windows.
The script needs to create a file on a network storage which is both configured to work with windows and UNIX permissions\security types.
Since the user that is running the script is an admin user all folders and files that it creates under all directories are no inheriting the directories permissions but makes it editable only to root.
What I try to do is create the file and than chmod it to the parent folder's "stat" results.
my ($perms, $uid, $gid) = (stat $ParentDirFullPath)[2, 4, 5];
$perms = sprintf("%04o", $perms & 0777);
chmod($perms, $NewFileFullPath);
The problem is that stat command on windows dosen't get the unix\gid and unix\uid + the chmod command is not really supported.
I looked into the file::stat module to find a way for displaying windows permissions(since they are present there too) to take them and apply them with a command that I didn't test yet that should be probably under the module Win32::FileSecurity.
I didn't find a way to get the permissions from there(I get stat=ARRAY(0x46d0f8)).
Any ideas or suggestions?
TL;DR:("How to?" question) Running Perl script on windows that takes parent folder permissions and applies them on a file that the scripts creates in the network storage that supports both Windows and Unix security/permissions types(the permissions that I want to apply are windows like permissions for groups and users).
Edit:
I tried the next code:
use Win32::FileSecurity qw(Get EnumerateRights);
use Win32;
my $dir1 = "\\\\NetworkStorage\\home\\user1";
my $dir2 = "\\\\NetworkStorage\\home\\user1\\PerlFileSecTest";
my %permissions;
Win32::FileSecurity::Get($dir1, \%permissions);
Win32::FileSecurity::Set($dir2, \%permissions);
And I get the next error:
S-1-5-11-2038111172-1292333386-11111-20315(this is not an original number and it changes this is unix FS user identifier that the AD knows how to parse)
Error handling error: 1332, LookupAccountName.
So it looks like the FileSecurity can't handle that user identifier that is coming from the unix based storage that supports both unixfs and NTFS.
This is strange because when I choose a folder for example and do "right click -> properties -> security tab" I see the numbers and then they are parsed to unixUid\user1 etc...
Any idea how to solve it?
Specifically for my case where the issue was the mixed mode on the network drive I found the next solution to be good enough for me.
I call the "icacls" system command and set permissions manually for the domain users from the folder above.
my $error = system("icacls $CreatedDir /grant domain\\user:(OI)(CI)F /T");
The code above gives full recursive permissions for the user to the folder that was created by the service with the admin user(which caused the folder to be locked only for the rood or admin user in our configuration).
Note that the command above doesn't override existing permissions but it was good enough for me.
So eventually I end up with a folder and files that are accessible to the user that called the specific service which runs with admin user.