View Issue Details

IDProjectCategoryView StatusLast Update
0001221OBS-StudioLinux (General)public2019-04-16 03:37
ReporterDubslowAssigned ToRytoEX 
PriorityhighSeveritymajorReproducibilityalways
Status resolvedResolutionno change required 
PlatformLinuxOSDebian stableOS Version9
Product Version21.1.1 
Target VersionFixed in Version 
Summary0001221: Running "checkinstall" command per build instructions destroys system permissions, rendering OS unusable
DescriptionSee this reddit comment and its surrounding thread for the details: https://www.reddit.com/r/linuxquestions/comments/8ctio8/extremely_confused_my_installation_just_most_of/dxim17z/

The summary is that running "sudo checkinstall --pkgname=obs-studio --fstrans=no --backup=no --pkgversion="$(date +%Y%m%d)-git" --deldoc=yes --install=no" per the build instructions, even with the extra "--install=no", removes the "other" permissions from "/usr/", "/usr/bin/", "/usr/lib/", and "/usr/share/obs" folders (while leaving others touched by the installation intact). The first three folders obviously contain critical programs and libraries for the basic operation of the OS, so making them invisible to users renders the system totally unusable to anyone who isn't root. (At least, unlike "rm -rf /", the fix is straightforward, at least if the root account exists. If the root account doesn't exist, then you need a live rescue disk to fix it.)

Per the reddit comment, the same command used on ffmpeg (again, per build instructions) did NOT produce this outcome, hence filing the bug report here instead of with checkinstall.
Steps To ReproduceInstall Debian 9 (unsure if this happens on similar distros, probably??)

"cd; mkdir obs; cd obs; git clone .; git checkout 21.1.1"
follow the build instructions from https://github.com/obsproject/obs-studio/wiki/Install-Instructions#debian-based-build-directions
the final command given there is:
sudo checkinstall --pkgname=obs-studio --fstrans=no --backup=no \ --pkgversion="$(date +%Y%m%d)-git" --deldoc=yes

^ This will nuke the permissions of /usr/, /usr/bin/, and /usr/lib/
TagsNo tags attached.

Activities

Dubslow

2018-04-17 16:51

reporter   ~0003258

Last edited: 2018-04-17 16:55

View 4 revisions

Er, various subfolders of /usr/share/obs/ also had bad permissions as well.

/usr/share/obs $ ls -l libobs/
total 88
-rw-r--r-- 1 root root 3892 Apr 16 19:35 bicubic_scale.effect
-rw-r----- 1 root root 1969 Oct 9 2016 bilinear_lowres_scale.effect
-rw-r----- 1 root root 1067 Oct 9 2016 default.effect
-rw-r----- 1 root root 596 Oct 9 2016 default_rect.effect
-rw-r----- 1 root root 8058 Oct 9 2016 deinterlace_base.effect
-rw-r----- 1 root root 990 Oct 9 2016 deinterlace_blend_2x.effect
-rw-r----- 1 root root 985 Oct 9 2016 deinterlace_blend.effect
-rw-r----- 1 root root 994 Oct 9 2016 deinterlace_discard_2x.effect
-rw-r----- 1 root root 988 Oct 9 2016 deinterlace_discard.effect
-rw-r----- 1 root root 994 Oct 9 2016 deinterlace_linear_2x.effect
-rw-r----- 1 root root 986 Oct 9 2016 deinterlace_linear.effect
-rw-r----- 1 root root 1000 Oct 9 2016 deinterlace_yadif_2x.effect
-rw-r----- 1 root root 994 Oct 9 2016 deinterlace_yadif.effect
-rw-r--r-- 1 root root 9971 Apr 16 19:35 format_conversion.effect
-rw-r--r-- 1 root root 4769 Apr 16 19:35 lanczos_scale.effect
-rw-r----- 1 root root 602 Oct 9 2016 opaque.effect
-rw-r----- 1 root root 657 Oct 9 2016 premultiplied_alpha.effect
-rw-r--r-- 1 root root 1528 Apr 16 19:35 solid.effect
/usr/share/obs $ ls -l obs-studio/
total 16
drwxr-x--- 2 root root 4096 Apr 16 21:08 license
drwxr-x--- 2 root root 4096 Apr 16 21:08 locale
-rw-r--r-- 1 root root 1330 Apr 16 19:35 locale.ini
drwxr-x--- 5 root root 4096 Apr 16 21:08 themes
/usr/share/obs $ ls -l obs-plugins/
total 60
drwxr-x--- 4 root root 4096 Apr 16 21:04 frontend-tools
drwxr-x--- 3 root root 4096 Oct 9 2016 image-source
drwxr-x--- 3 root root 4096 Oct 9 2016 linux-capture
drwxr-x--- 3 root root 4096 Oct 9 2016 linux-decklink
drwxr-x--- 3 root root 4096 Oct 9 2016 linux-jack
drwxr-x--- 3 root root 4096 Oct 9 2016 linux-pulseaudio
drwxr-x--- 3 root root 4096 Oct 9 2016 linux-v4l2
drwxr-x--- 3 root root 4096 Apr 16 21:08 obs-ffmpeg
drwxr-x--- 4 root root 4096 Apr 16 21:08 obs-filters
drwxr-x--- 3 root root 4096 Oct 9 2016 obs-outputs
drwxr-x--- 4 root root 4096 Apr 16 21:08 obs-transitions
drwxr-x--- 3 root root 4096 Oct 9 2016 obs-x264
drwxr-x--- 3 root root 4096 Apr 16 21:08 rtmp-services
drwxr-x--- 3 root root 4096 Apr 16 21:08 text-freetype2
drwxr-x--- 3 root root 4096 Apr 16 21:04 vlc-video

Looks like files written by the installation were fine, but files *checked without modification* were the ones with permissions destroyed, while folders had their permissions destroyed whether or not they were modified. Or something like that.

/usr/share/obs/obs-plugins $ ls -l frontend-tools/
total 8
drwxr-x--- 2 root root 4096 Apr 16 21:08 locale
drwxr-xr-x 3 root root 4096 Apr 16 21:08 scripts

Or maybe not. Looks somewhat arbitrary what is wrong and what isn't

Osiris

2018-04-17 17:29

developer   ~0003259

Last edited: 2018-04-17 17:30

View 2 revisions

I have done this command multiple times on my ubuntu machine and it has never altered permissions of /usr, /usr/lib or /usr/bin
The permissions on the OBS stuff also doesn't look like that on my machine, you also seem to be having files there from 2016.

Dubslow

2018-04-17 21:23

reporter   ~0003261

Yes I had run the build instructions, with the same checkinstall command, just fine several months ago (a version with a leading 0.x in the version number).

Not sure what's different this time, other than the version upgrade

elo

2018-05-03 09:03

reporter   ~0003289

Last edited: 2018-05-03 09:05

View 2 revisions

Dropping by to confirm that I also experienced this (On Kubuntu 18.04).

So, I'd suggest changing the "OS" in this issue as it seems to be affecting debian and its derivatives.

CommanderStrax

2018-05-24 19:15

reporter   ~0003297

Last edited: 2018-05-24 19:18

View 2 revisions

Confirming this issue on Arch Linux as well. It definitely worked before OBS 21 was released.

RytoEX

2018-07-25 05:22

manager   ~0003373

I'm still not convinced this is an issue that occurred because something in the OBS repo changed. I'd sooner think that it was something in your distros checkinstall (or a related/called utility) or config that changed that is now exposing this behavior, somehow. I'm not aware of anything in the OBS code base that tells checkinstall whether or not to change folder permissions.

Debian 9.4 was released on March 10, 2018 (reporter only specified "Debian stable", not specifically 9.4, so this is a guess). Kubuntu 18.04 was released on April 26, 2018.

Does this same problem still occur if you manually checkout a version of OBS before 21.1.1 or before 21.0.0? Does the same problem occur when using sudo make install (note, you will have to manually remove files created/installed this way)? What about just checkinstall with no sudo?

It might be of interest to see the contents of your /etc/checkinstallrc file (for example, the values of CKUMASK and RESET_UIDS). It _almost_ sounds like either you've got a strange umask setting or --reset-uids is being passed to checkinstall (or its enabled in your rc), which would reset perms for all files to o=g, dirs to 755 and the owner/group for all dirs to root.root.

RytoEX

2018-09-11 14:28

manager   ~0003606

@Dubslow @elo @CommanderStrax
Any updates with respect to my comment above? I don't want to arbitrarily close this, but my investigation points to a config issue with checkinstall and not something specific to the OBS build process. You _could_ probably pass an arg to checkinstall to avoid this behavior, though I don't recall the specific flag combination needed. If you know the specific flag combination needed (possibly just "--reset-uids=no" or some umask/reset-uids combination), please provide it here.

In the meantime, I'm going to downgrade the priority and severity of this. If someone can answer my questions above or provide more insight into their checkinstall configs, that would help isolate this issue. If nothing conclusive is found by September 30, 2018, I'm inclined to close this issue, unless someone can clearly illustrate that this is an issue with OBS itself. If the standard Debian-based build instructions have changed with respect to checkinstall, that is something we can address in the build instructions on the wiki, but I'm not familiar enough with those systems to just make a change right now without more information.

CommanderStrax

2018-09-20 19:05

reporter   ~0003644

Last edited: 2018-09-20 19:06

View 2 revisions

@RytoEX sorry, completely forgot about this. Arch doesn't use checkinstall. In my case I used the AUR PKGBUILD which utilizes CMAKE. PKGBUILD can be found here -> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=obs-studio-git. CMAKE uses /etc/makepkg.conf which is provided by the pacman package, which was updated on 20th of April and on 28th of May. I updated pacman on my system on 8th of May according to my pacman.log.

Checking the history of makepkg.conf however, it turns out that that file wasn't changed with that update -> https://git.archlinux.org/svntogit/packages.git/log/trunk/makepkg.conf?h=packages/pacman

I would usually admit that this could be due to one of the many (other) changes on a Arch installation - however due to at least two other users that used completely different distributions I deem this unlikely.

RytoEX

2018-09-20 21:15

manager   ~0003645

@CommanderStrax
I'd typed up a long reply, and then it got eaten.

Basically, I still don't see anything on OBS side that would have changed this behavior. My opinion is still that distros or tools changed something between March and May 2018.

If someone can test the 20.1.3 tag and the 21.0.0 tag for each behavior and document it here showing a change in behavior _just_ from OBS code changes, that may change my evaluation. Bonus points if you can do a bisect and find a specific commit.

CommanderStrax

2018-10-16 18:08

reporter   ~0003683

Didn't have time to check those versions but I checked the current git version and I'm not seeing this behaviour anymore.

Fenrir

2019-04-16 03:37

administrator   ~0004503

Marking resolved per above comment. Likely an environment issue.

Issue History

Date Modified Username Field Change
2018-04-17 16:39 Dubslow New Issue
2018-04-17 16:51 Dubslow Note Added: 0003258
2018-04-17 16:52 Dubslow Note Edited: 0003258 View Revisions
2018-04-17 16:53 Dubslow Note Edited: 0003258 View Revisions
2018-04-17 16:55 Dubslow Note Edited: 0003258 View Revisions
2018-04-17 17:29 Osiris Note Added: 0003259
2018-04-17 17:30 Osiris Note Edited: 0003259 View Revisions
2018-04-17 21:23 Dubslow Note Added: 0003261
2018-05-03 09:03 elo Note Added: 0003289
2018-05-03 09:05 elo Note Edited: 0003289 View Revisions
2018-05-24 19:15 CommanderStrax Note Added: 0003297
2018-05-24 19:18 CommanderStrax Note Edited: 0003297 View Revisions
2018-07-25 05:22 RytoEX Assigned To => RytoEX
2018-07-25 05:22 RytoEX Status new => assigned
2018-07-25 05:22 RytoEX Note Added: 0003373
2018-09-11 14:28 RytoEX Priority urgent => high
2018-09-11 14:28 RytoEX Severity block => major
2018-09-11 14:28 RytoEX Note Added: 0003606
2018-09-20 19:05 CommanderStrax Note Added: 0003644
2018-09-20 19:06 CommanderStrax Note Edited: 0003644 View Revisions
2018-09-20 21:15 RytoEX Note Added: 0003645
2018-10-16 18:08 CommanderStrax Note Added: 0003683
2019-02-23 07:46 RytoEX Category General => Linux (General)
2019-04-16 03:37 Fenrir Status assigned => resolved
2019-04-16 03:37 Fenrir Resolution open => no change required
2019-04-16 03:37 Fenrir Note Added: 0004503