2016-11-28 4 views
0

Я не очень большой разработчик Perl, но мне нужно, чтобы он запускал триггеры.Что лучше всего подходит для Perl, получая разрешения на родительские папки во время работы в Windows.

Так что это фон:
У меня есть служба Windows, которая запускается как администратор, который вызывает скрипт Perl на окнах.

Скрипт должен создать файл в сетевом хранилище, который настроен на работу с разрешениями Windows \ UNIX \ security.

Поскольку пользователь, выполняющий скрипт, является пользователем admin, все папки и файлы, которые он создает во всех каталогах, не наследуют разрешения каталогов, а делают его доступным для редактирования только для root.

Что я пытаюсь сделать, так это создать файл, а не chmod его на «stat» в родительской папке.

my ($perms, $uid, $gid) = (stat $ParentDirFullPath)[2, 4, 5]; 
$perms = sprintf("%04o", $perms & 0777); 
chmod($perms, $NewFileFullPath); 

Проблема заключается в том, что stat команда на окнах dosen't получить Unix \ GID и UNIX \ UID + команда chmod не очень поддерживается.

Я просмотрел модуль file::stat, чтобы найти способ отображения разрешений Windows (так как они присутствуют там тоже), чтобы взять их и применить их с помощью команды, которую я еще не тестировал, что должно быть, вероятно, под модулем Win32::FileSecurity , Я не нашел способ получить разрешения оттуда (я получаю stat=ARRAY(0x46d0f8)).

Любые идеи или предложения?

TL; DR :(Вопрос «Как?») Запуск сценария Perl в окнах, которые разрешают родительские права доступа к папкам и применяют их к файлу, создаваемому сценариями в сетевом хранилище, который поддерживает типы безопасности и разрешений Windows и Unix (разрешения, которые я хочу применить, - это окна, подобные разрешениям для групп и пользователей).

Edit:
Я попытался следующий код:

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); 

И я получаю следующую ошибку:

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. 

Так выглядит как FileSecurity не может обработать этот идентификатор пользователя, который исходя из хранилища на основе unix, которое поддерживает как unixfs, так и NTFS.

Это странно, потому что, когда я выбираю папку для примера и сделать «правой кнопкой мыши -> Свойства -> вкладка Безопасность» Я вижу цифры, а затем они обрабатываются в unixUid \ user1 и т.д. ...

Любой Идея, как его решить?

+0

Я попробую это решение, и я обновлю: http://stackoverflow.com/a/302694/5965588 'my% permissions; Win32 :: FileSecurity :: Get ($ dir, \% permissions); $ permissions {'Power Users'} = MakeMask (qw (READ GENERIC_READ GENERIC_EXECUTE))}); Win32 :: FileSecurity :: Set ($ dir, \% permissions); ' – MaxBk

+0

Работа с FileSecurity почти сработала, но только для« Get »не для« Set ». Дополнительная информация в разделе «редактировать». – MaxBk

ответ

0

В частности, для моего случая, когда проблема была в смешанном режиме на сетевом диске, я нашел следующее решение для меня достаточно хорошим.

Я вызываю системную команду «icacls» и устанавливаю права вручную для пользователей домена из указанной выше папки.

my $error = system("icacls $CreatedDir /grant domain\\user:(OI)(CI)F /T"); 

Код выше, дает полные рекурсивные разрешения для пользователя в папку, которая была создана с помощью службы с пользователем администратору (который вызвал папку быть заблокирован только для Руд пользователя или администратора в нашей конфигурации).

Обратите внимание, что команда выше не переопределяет существующих разрешений, но это было достаточно для меня.

Так что в итоге я получаю папку и файлы, доступные пользователю, вызывающему конкретную службу, которая запускается с пользователем администратора.