Action scripting running with wrong user context (root instead of saned)
scanbd is a scanner button daemon looking for scanner button pressed
Brought to you by:
wimalopaan
Menu
▾
▴
1 Attachments
#16 Action scripting running with wrong user context (root instead of saned)
Hi, I am using scanbd 1.4.1 as bundled with Ubuntu 16-04 LTS.
I have configured scanbd to run as saned user which works fine. Now, if saned starts a script triggered by pressing a scanner button this script is being executed as root. Which is IMO a bad idea.
First order of business: Assuming I have made a mistake configuring scanbd correctly. Please find enclosed my scanbd.conf. Any idea where else to look for configuration information that might be responsible for the observed behavior?
Thanks and sorry for bothering,
Christoph
Related
That shouldn't happen!
The config looks fine.
Please check if scanbd is running with the intended uid/gid.
This is what I can find out about euid and egid:
PID UID USER GID GROUP COMMAND
3467 108 saned 109 scanner /usr/sbin/scanbd -f
My scan script starts as follows:
myid=
idlogger -t "scanbd: $0" "Begin of $SCANBD_ACTION for device $SCANBD_DEVICE, running as $myid"
The output from syslog is:
Feb 19 16:29:18 scanbd: /usr/share/scanbd/scripts/scanfujitsu.script: Begin of scan for device fujitsu:ScanSnap iX500:34586, running as uid=0(root) gid=0(root) groups=0(root)
Temporary directory created next is owned by root. So everything looks as if root is the euid for the action script.
If there is anything else I can try, please let me know.
Christoph
Related
Tickets:
#16Please switch to the sane mailing list.
I have to reproduce this error but actually don't have the time to do that in the next days ...
I spent some more time on this thing.
Compiled 1.4.4 from sourceforge. I can reproduce the behavior I have described. I added some additional logging before and after the fork() right before the execle() of the script.
Logging shows that euid and ruid are just fine. But then when the script gets exec'ed euid and ruid of the script are still both 0.
Not good. Looks to me like some kind of kernel strangeness which I find very hard to believe in this basic functionality. Any idea how to pursue that further? Still hoping I do a stupid mistake somewhere...
Christoph
I did some more research on this. Seems that bash is resetting the effective UID to the real UID. Since scanbd does not drop privileges completely, but only changes the effective UID, this leads to the actual action script being executed with root privileges.
I applied some changes in dbus.c right before the exec for the script happens to setreuid the real and effective UIDs to the one configured in scanbd.conf. That seems to do the trick.
If you are interested I can supply the details.
I also investigated on the SEGV when a device is connected or disconnected. Will answer in the respective ticket. Would be interested to get your opinion on my reasoning.
Christoph
should be fixed in trunk and 1.4.6
I spent some more time on this thing.
Compiled 1.4.4 from sourceforge. I can reproduce the behavior I have described. I added some additional logging before and after the delta fork() right before the execle() of the script.
Last edit: aenam 2025-05-15
Looks to me like some kind of minecraft download kernel strangeness which I find very hard to believe in this basic functionality. Any idea how to pursue that further?
Last edit: aenam 2025-06-12
I applied some changes in dbus.c right before the exec for the app script happens to setreuid the real and effective UIDs to the one configured in scanbd.conf.
Last edit: carrillo 2025-10-20
I had a similar user context issue on a different project. For my gaming APK site, I solved it by explicitly setting the user in the script header with #!/bin/bash -u and defining UID before exec. The fork behavior you described matches what I saw. Check if bash is resetting the effective UID like Christoph mentioned. That was the culprit for me.