Allow sound for 'remote' browser

[charlie101]

I've set up Icecat as my browser using a 'dummy' account. To run the browser I call a simple script which SU's to the dummy user and calls icecat. To allow access to the X server I use the xhost command and the browser works fine accept for the fact that I can't get any sound from the browser. I'm assuming this is a permission problem and I'm hoping there is a simple grant or xhost type command I can use?

Any advice or pointers would be gratefully received.

I'm on Debian 10.

Thanks in advance.

charlie101

[Head_on_a_Stick]

I've set up Icecat as my browser

The latest version of that browser is massively outdated and so should not be used at all.

To run the browser I call a simple script which SU's to the dummy user and calls icecat.

Then you should probably share the script here.

I use the xhost command

That sounds unwise.

I'm hoping there is a simple grant or xhost type command I can use?

I think firejail would be much more sensible.

[charlie101]

Hi Head_on_a_Stick

Thank you for your reply.

I'm using icecat because it seems to be easier to set privacy and anti tracking settings than firefox.
It also seems to do a better job of blocking ad's etc than firefox and doesn't open any anonymous unsolicited connections in the back ground.
I find trawling through all the 'hidden' settings a bit of a pain in firefox.
Of couse I'm not wedded to icecat and would be happy to change given a concrete issue.

I didn't want to use firejail as I believe it uses a setuid. Avoiding 'setuid' was the reason I chose to use a dummy user account instead.
If I can get it working smoothly I can then think about rapping some namespace commands etc around it to further isolate the account.
The dummy user account also makes it very easy to automate the scrubbing and resetting of that account between uses
I'd be happy to receive any better ideas.

I'd be grateful if you would mention what the issue is with xhost and if there is a better way of allowing limted access to my xserver?

Also, my original question about 'granting' access to sound' remains unaddressed.
I'd be grateful if anyone can shed some light on that.

Thanks again for your reply..

Charlie101

[Head_on_a_Stick]

Of couse I'm not wedded to icecat and would be happy to change given a concrete issue

See https://www.mozilla.org/en-US/security/ ... s/firefox/ ← check all the vulnerabilities for v60 onwards.

I'd be grateful if you would mention what the issue is with xhost and if there is a better way of allowing limted access to my xserver?

And I'd be grateful if you'd share your script so that we can see exactly how you're using the command.

Also, my original question about 'granting' access to sound' remains unaddressed

Is the dummy user a member of the audio group? That's just a stab in the dark though, I might be able to help more if you show us this mysterious, super-secret script...

[charlie101]

Update (?solved? - working)
The fact that icecat worked when run from my gnome login account and not when I did a ‘su’ to a dummy account led me to assume that it was probably a permissions problem. As is often the case it turns out to be slightly more complicated with several elements in play.

1) There is apparently a ‘bug’ in gnome which seems to cause problems with some programs when they are run under ‘su’ although the same programs when run under a sudo spawned account work just fine.
2) This led me to put more effort into tracing the specific errors generated by icecat under my ‘su – dummy’ environment. I found that a number of the initial errors were caused by the fact that the spawned shell had inherited all the environmental settings from its parent. Consequently the dummy shell had all the settings from my login shell even though I specified: ‘su – dummy’. This was easily remedied with an explicit execution of an ‘env’ file.
3) Next a slew of errors were caused by the fact that icecat run under ‘dummy’ could not create a dconf directory under /run/user, even though icecat run under my logged in account had no such problem (I didn’t try running it under sudo). I hacked this problem by simply creating the directory manually in order to get on and trace the rest of the problems: '/run/user/USER_ID'.
4) Finally I got an explicit audio related error:
[Child 17696, MediaPlayback #4] WARNING: Decoder=7fc9c5a20020 [OnMediaSinkAudioError]: file /home/ruben/git/gnuzilla/output/icecat-60.7.0/dom/media/MediaDecoderStateMachine.cpp, line 3385

Well, given that I don’t have any ‘ruben’ account on my machine or any such directory, I assumed this value of ‘/home/ruben/git’ was dredged up from the bowels of somewhere I didn’t want to go. That and the slew of accompanying java errors made me call it a day on icecat.

Consequently I switched to firefox and it’s working 'fine' although it still has the environment variables issue and it can’t create the /run/user/USER_ID/ directory: ‘/run/user/1004’ in my case. This would seem to be related to the reported gnome su 'bug'.

Head_on_a_stick. I didn’t include my script because it is a trivial script. I also thought my description of what I’d done basically told anyone who was interested what was in it:
a) su
b) xhost
c) Call to icecat launcher
d) Possibly a script to clean down the account after/between use(s). I alluded to this possibility further down from the initial description of my problem.

Not exactly rocket science but I apologize if I wasn’t clear enough. Anyway, here is the script for anyone who wants the syntax. It is rather simple and ugly but I’ve only just got it ‘working’. I might post an update when I get round to tidying it up and adding some additional ‘lockdown’ commands.

#------------ Simple SU script --------------------

xhost +local:dummy@
echo -e "PASSWORD\n" | su - dummy -s /bin/sh -c '. ./.setenv ; /usr/lib/firefox-esr/firefox-esr'
xhost -local:dummy@

sudo -i -u dummy /config-files/Broswer-security/Browser-installation/refresh-dummy.sh

#=-----------------------------------------------------

Thanks again for your help

Charlie101