Automatically created dependancy folders by modules have wrong permissions and owner

[y0014984]

Introduction

If you create files and folders via the addFile or addDir module in a non-existing subfolder, this folder will be vreated automatically. For example if you create the file test1 in path /test/new/, then the folders test and new are automatically created as an dependancy. for this file.

Unfortunately, the created folders have not very useful permissions or owners. Here are some examples:

Example 1 - addFolder Module

Settings | /folder1/folder2 admin rwxrwx (drawer)

Behavior /folder1 root rwx--- (drawer) /folder1/folder2 admin rwxrwx (drawer)

expected behavior /folder1 admin rwxrwx (drawer) /folder1/folder2 admin rwxrwx (drawer)

In this example everyone would be allowed to enter the target folder but is not allowed to enter the parent folder. Also the owner of the parent folder changed to root unnecessarily.

Example 2 - addFile Module

Settings /folder1/file1 admin --x--x (file)

Behavior /folder1 admin ------ (drawer) /folder1/file1 admin --x--x (file)

Expected Behavior /folder1 admin -rx-rx (drawer) /folder1/file1 admin --x--x (file)

in this example no one, not even the owner, is allowed to enter the parent directory (x is needed) or to list the directories content (r is needed).

Conclusion

There are some inconsistencies that should be fixed. The Owner should always be the one of the target file oder folder. Also the parent folders should always allow you to use your rights on the target filesystem object. Therefore every parent directory should allow entering (x) if you have any right on the file like r,w or x. In that case you should also have the right to read the directories contents (r). Some Examples:

target object	parent directory
r-- ---	r-x ---
-w- ---	r-x ---
--x ---	r-x ---
--- r--	--- r-x
--- -w-	--- r-x
--- --x	--- r-x

[y0014984]

@GermanHydrogen could you have a look into it?

[y0014984]

Result of first test: If file permissions contain only an "r", the parent folder will get an "x", but if the file permissions only contain an "x" or a "w", the parent folder will not get an "x". In case of "w" it does not seem necessary but in case of "x" you should be able to enter and list the parent folders contents. This is the corresponding current code:

//Set R-Permissions as X-Permissions, so a newly created folder with a R-Only-File could be entered
private _rOwner = (_permissions select 0) select 1;
private _rOthers = (_permissions select 1) select 1;
private _ownerPerms = +(_permissions select 0);
private _othersPerms = +(_permissions select 1);
_ownerPerms set [0, _rOwner];
_othersPerms set [0, _rOthers];
private _modifiedPerms = [_ownerPerms, _othersPerms];

(_current select 0) set [_x, [createHashMap, _owner, _modifiedPerms]];

[y0014984]

The "r" permission always overwrites the "x" permission. This leads to the case, that a missing "r" permission overwrites an existing "x" permission with false (=deny). The complete approach should be overhauled.

[y0014984]

When creating a folder/directory, the function fnc_createDir.sqf does not give the _owner variable as a parameter to the fnc_getParentDir.sqf function. The default in this function is to substitue the missing _owner with the command executing _user which is always root in this case.

[y0014984]

Fixed in #351