Least privilege permissions

[JanLenoch 1]

Hello,

Is it possible to have the EmbyServer.exe process have other than administrator permissions?

I just purchased a lifetime Premiere subscription and installed my server. It runs on Windows 11 and takes the TV signal from a Hauppauge WinTV-quadHD PCIe tuner. I also have my server exposed publicly, behind an IIS reverse proxy that also does SSL termination. After installing Emby Server with my administrator account, I moved all its %AppData% folders into a dedicated user account that was temporarily a member of the machine's Administrators group. Then, I used NSSM to install Emby Server as a Windows service, using that dedicated account. I planned on removing all of the group memberships from the dedicated account and assigning it just the "Remote Desktop Users" permission on an ad-hoc basis, when I need to update Emby via RDP.

However, when I recently removed the service account from Administrators, it turned out that live TV stopped working, saying "No compatible streams are currently available. Please try again later or contact your system administrator for details." I haven't altered any WinTV settings. WinTV plays TV without problems.

I did an experiment and assigned the HauppaugeTVServer Windows service the same dedicated account as the Emby Server runs on. I didn't give it many chances and expected that even WinTV could stop working. My worries proved true, so I reverted the HauppaugeTVServer service back to the default system account it was originally installed with. When I make the Emby's service account a member of Administrators, live TV starts working again.

Although I have my server behind the reverse proxy, I still cannot accept having Emby running with admin permissions. In case of an attack, such membership is an open door to the whole machine. I searched through these forums for a solution to no avail.

Could anyone tell whether it is possible to lower the EmbyServer.exe permissions to some bearable level?

I'm a .NET developer and a former AD admin myself so it's sad that you Emby authors no longer have the server's source on GitHub (as far as I know). Usually, when I encounter such problems, I look around in forums and then I clone the source to find the definitive answer. In this case, I'm blind and will need someone's help.

BTW, apart from this issue, I'm pleased by the usability, speed, and reliability of Emby. I've been using Plex for two years and realized I don't need a ton of "features for features". Instead, having the important features work as expected is what matters at the end of the day. Great job guys!

Thank you.

[Abobader 3464]

Hello JanLenoch,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

[rbjtech 5284]

Hi - yes I run the process under a non-admin windows Service Account - the key to getting it working is actually in the file / ntfs permissions.   Emby will need read/write on all it's file locations (cache/db etc) - it will also need write to the media shares IF you write metadata there, if not, then RO will do.

Emby has no concept of split permissioning, so the account you run it under will be the account used for access - thus it is key to use a Service Account as you have already ascertained.

I don't use a Hauppauge (I use HR Homerun) - so it's possible that interface does need Admin - but I'd be surprised if it did.

Edited June 6, 2023 by rbjtech

[JanLenoch 1]

Hi, thanks for your input.

At first, I was skeptical that the issue might be just filesystem-related. But I gave it a try and assigned explicit NTFS write permissions to the service account for the following locations:

• Program Files (x86)\WinTV\
• Users\Public\WinTV\
• Users\Public\Videos\

But no, after removing the service account from Administrators and restarting the EmbyServer.exe process, the same error message showed up.

I think I'll need advice from one of the authors of the product.

Anyways, thanks for your ideas, rbjtech!

[rbjtech 5284]

What's the actual error message ?

If you turn on debug logging and ping me a log when it happens, I'm happy to take a look - or PM Luke and/or Eric if you'd rather - but without a log, it's going to be very difficult to help pinpoint the actual permission error.

[JanLenoch 1]

I peeked the logs before but I'm afraid they are still of no value to people without the access to the source and knowledge of the Hauppauge stack architecture.

It throws NRE at Emby.LiveTV.EmbyTV.GetChannelStreamWithDirectStreamProvider(), apparently due to List`1 currentLiveStreams being either empty or completely null. Upper in the call stack, right before that call, the MediaBrowser.Controller.LiveTv.BaseTunerHost.GetChannelStream method reports having just three out of five parameters populated (leaving CancellationToken aside). That List`1 currentLiveStreams argument is already missing in this call.

The Emby.LiveTV.TunerHosts.Hauppauge.HauppaugeTunerWindows.GetChannelStream method, which immediately precedes these above two methods in the call stack, fails to supply that list of streams.

However, the log only tells us that this method fails to supply the list of streams, not why.

I attached a stripped debug log. If the full log is needed, I'd rather send it in PM.

debug-log-1.txt

[rbjtech 5284]

4 hours ago, JanLenoch said:

I peeked the logs before but I'm afraid they are still of no value to people without the access to the source and knowledge of the Hauppauge stack architecture.

It throws NRE at Emby.LiveTV.EmbyTV.GetChannelStreamWithDirectStreamProvider(), apparently due to List`1 currentLiveStreams being either empty or completely null. Upper in the call stack, right before that call, the MediaBrowser.Controller.LiveTv.BaseTunerHost.GetChannelStream method reports having just three out of five parameters populated (leaving CancellationToken aside). That List`1 currentLiveStreams argument is already missing in this call.

The Emby.LiveTV.TunerHosts.Hauppauge.HauppaugeTunerWindows.GetChannelStream method, which immediately precedes these above two methods in the call stack, fails to supply that list of streams.

However, the log only tells us that this method fails to supply the list of streams, not why.

I attached a stripped debug log. If the full log is needed, I'd rather send it in PM.

debug-log-1.txt 2.21 kB · 0 downloads

Agreed, they are not advising much - maybe @softworkzcould advise the best route here - but I suspect, as you do, that the issue probably lies with the Hauppauage stack needing Admin permissions to create the streams.

[softworkz 5071]

@JanLenochFirst of all, let me say that you're on the right track with everything you did so far. I recently proposed internally to change the Windows installation method and make it the  default to install Emby Server as a Windows Service under a (new or existing) user account with limited privileges. It's in fact a very bad idea to run a public-facing service under the account of the user who installs the server.

Regarding Hauppauge tuner support, I am not familiar with details of the implementation. But what I can tell is that this is going through execution of HauppaugeWindowsProvider.exe which is included in Emby Server. 
In order to determine which specific privileges are missing you could run SysIntermals' ProcessMonitor. Set it up to filter by executable name (HauppaugeWindowsProvider.exe) and trigger the channels update. From the output you might be able to determine the permissions (registry, file, COM activation) which you need to assign to your service account to get it working.

[JanLenoch 1]

Hi guys, great idea with ProcessMonitor! Mark Russinovich to the rescue.  I'll have to try it out tomorrow (it's midnight here in Europe) but one thing is for sure by now. You guys rock! Thanks!

BTW, I was also suspecting there would be some other process involved since my instance of DVBGuide.exe talks to my tuner without any machine-level permissions. DVBGuide apparently touches directly the BDA drivers, not that proxy process. I realize this might be a long way to go to rework the architecture in the future. Therefore, if you think I might be of any value if I get involved, just let me know.

[softworkz 5071]

3 minutes ago, JanLenoch said:

I realize this might be a long way to go to rework the architecture in the future.

Not anymore. We've fully walked this way already and have a completely new TV implementation (code name 'TVnext') which is using BDA natively on Windows and LinuxTV APIs on Linux (and much much more).

[JanLenoch 1]

Hi @softworkz! Any idea when the 'TVnext' implementation goes RTM? Is there a chance it might happen with the 4.8 server release? Thanks.

[pwhodges 2012]

No chance - given that 4.8 is already released :~)

But if it doesn't appear quite early in the 4.9 beta round, some people will be seriously pissed off...

Paul

[TMCsw 249]

5 hours ago, JanLenoch said:

RTM?

Are you 90 or living in the 90's 

But seriously I think TVnext should be the next public beta...