View Issue Details

IDProjectCategoryView StatusLast Update
0001162bareos-core[All Projects] file daemonpublic2019-12-18 18:44
ReporteraroggeAssigned Toarogge 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Version19.2.4~pre 
Fixed in Version19.2.4~rc1 
Summary0001162: When restoring files without directories, the permissions of the immediate parent directory are wrong
DescriptionIf you restore files (and not directories) with a restore job and the parent directories are created by the filedaemon, then these directories will have weird permission bits set.
Steps To Reproduce1. start restore browser
2. select a single file in any non-top directory
3. restore to a non-existant location
4. observe weird permission bits on the file's immediate parent directory
Additional InformationIt looks like the filedaemon guesses what permission the directory should have based on the file that is being restored. This is inconsistent and the whole behaviour should probably be rewritten sometime.
TagsNo tags attached.
bareos-master: impactyes
bareos-master: actionfixed
bareos-19.2: impactyes
bareos-19.2: actionwill care
bareos-18.2: impactyes
bareos-18.2: actionwill care
bareos-17.2: impactyes
bareos-17.2: actionwill care
bareos-16.2: impactyes
bareos-16.2: actionwill care
bareos-15.2: impact
bareos-15.2: action
bareos-14.2: impact
bareos-14.2: action
bareos-13.2: impact
bareos-13.2: action
bareos-12.4: impact
bareos-12.4: action

Relationships

related to 0001156 closedarogge Release Bareos 19.2.4 
related to 0001157 confirmed Release Bareos 18.2.8 
related to 0001158 confirmed Release Bareos 17.2.9 
related to 0001159 new Release Bareos 16.2.10 

Activities

arogge

arogge

2019-12-18 17:22

developer   ~0003702

Fix committed to bareos master branch with changesetid 12446.

Related Changesets

bareos: master 03d68733

2019-12-17 17:25:49

arogge

Ported: N/A

Details Diff
findlib: parent dirs should have consistent mode

Fixes 0001162: When restoring files without directories, the permissions
of the immediate parent directory are wrong

Previously when creating parent directories Bareos handled the deepest
parent directory special and set permissions on it.
This surfaced when selecting only files, but not directories to restore.
In that case the directory that contains the files got a mode that was
derived from the file mode of the file being restored when the parent
directory was created.
While this in itself is already inconsistent, the effective mode was
also calculated by adding S_IWUSR and S_IXUSR which did not take group
or other in account.

This patch now makes sure that no permission on parent directories is
set explicitly, so you just get what the effective uid, gid and umask
will produce.
Affected Issues
0001162
mod - core/src/findlib/mkpath.cc Diff File

bareos: bareos-16.2 5eb993c4

2019-12-17 17:25:49

arogge

Ported: N/A

Details Diff
findlib: parent dirs should have consistent mode

Previously when creating parent directories Bareos handled the deepest
parent directory special and set permissions on it.
This surfaced when selecting only files, but not directories to restore.
In that case the directory that contains the files got a mode that was
derived from the file mode of the file being restored when the parent
directory was created.
While this in itself is already inconsistent, the effective mode was
also calculated by adding S_IWUSR and S_IXUSR which did not take group
or other in account.

This patch now makes sure that no permission on parent directories is
set explicitly, so you just get what the effective uid, gid and umask
will produce.

(cherry picked from commit 705860721722284540ef8d74461c5a7b772c6da1)
Affected Issues
0001162
mod - src/findlib/mkpath.c Diff File

bareos: bareos-17.2 1b5ff848

2019-12-17 17:25:49

arogge

Ported: N/A

Details Diff
findlib: parent dirs should have consistent mode

Previously when creating parent directories Bareos handled the deepest
parent directory special and set permissions on it.
This surfaced when selecting only files, but not directories to restore.
In that case the directory that contains the files got a mode that was
derived from the file mode of the file being restored when the parent
directory was created.
While this in itself is already inconsistent, the effective mode was
also calculated by adding S_IWUSR and S_IXUSR which did not take group
or other in account.

This patch now makes sure that no permission on parent directories is
set explicitly, so you just get what the effective uid, gid and umask
will produce.

(cherry picked from commit 705860721722284540ef8d74461c5a7b772c6da1)
Affected Issues
0001162
mod - src/findlib/mkpath.c Diff File

bareos: bareos-18.2 68c99eb5

2019-12-17 17:25:49

arogge

Ported: N/A

Details Diff
findlib: parent dirs should have consistent mode

Previously when creating parent directories Bareos handled the deepest
parent directory special and set permissions on it.
This surfaced when selecting only files, but not directories to restore.
In that case the directory that contains the files got a mode that was
derived from the file mode of the file being restored when the parent
directory was created.
While this in itself is already inconsistent, the effective mode was
also calculated by adding S_IWUSR and S_IXUSR which did not take group
or other in account.

This patch now makes sure that no permission on parent directories is
set explicitly, so you just get what the effective uid, gid and umask
will produce.

(cherry picked from commit 705860721722284540ef8d74461c5a7b772c6da1)
Affected Issues
0001162
mod - core/src/findlib/mkpath.cc Diff File

Issue History

Date Modified Username Field Change
2019-12-18 16:01 arogge New Issue
2019-12-18 16:01 arogge Status new => assigned
2019-12-18 16:01 arogge Assigned To => arogge
2019-12-18 17:22 arogge Changeset attached => bareos master 03d68733
2019-12-18 17:22 arogge Note Added: 0003702
2019-12-18 17:22 arogge Status assigned => resolved
2019-12-18 17:22 arogge Resolution open => fixed
2019-12-18 18:35 arogge Status resolved => new
2019-12-18 18:35 arogge Resolution fixed => reopened
2019-12-18 18:36 arogge Status new => assigned
2019-12-18 18:37 arogge Fixed in Version => 19.2.4~rc1
2019-12-18 18:37 arogge bareos-master: impact => yes
2019-12-18 18:37 arogge bareos-master: action => fixed
2019-12-18 18:37 arogge bareos-19.2: impact => yes
2019-12-18 18:37 arogge bareos-19.2: action => will care
2019-12-18 18:37 arogge bareos-18.2: impact => yes
2019-12-18 18:37 arogge bareos-18.2: action => will care
2019-12-18 18:37 arogge bareos-17.2: impact => yes
2019-12-18 18:37 arogge bareos-17.2: action => will care
2019-12-18 18:37 arogge bareos-16.2: impact => yes
2019-12-18 18:37 arogge bareos-16.2: action => will care
2019-12-18 18:37 arogge Status assigned => resolved
2019-12-18 18:37 arogge Resolution reopened => fixed
2019-12-18 18:40 arogge Status resolved => new
2019-12-18 18:40 arogge Resolution fixed => reopened
2019-12-18 18:40 arogge Relationship added related to 0001156
2019-12-18 18:40 arogge Relationship added related to 0001157
2019-12-18 18:40 arogge Relationship added related to 0001158
2019-12-18 18:40 arogge Relationship added related to 0001159
2019-12-18 18:42 arogge Status new => resolved
2019-12-18 18:42 arogge Resolution reopened => fixed
2019-12-18 18:43 arogge Changeset attached => bareos bareos-16.2 5eb993c4
2019-12-18 18:43 arogge Changeset attached => bareos bareos-17.2 1b5ff848
2019-12-18 18:44 arogge Changeset attached => bareos bareos-18.2 68c99eb5