> But if you used user saned.saned why bash tried to access /root? > And if you run as root why it couldn't read inside /root?
I think it has to do with the fact that when root starts a new shell with reduced permissions, the new shell tries to read /root/.bashrc If it can't read it then it is a non-fatal warning but it outputs the warning to stderr which, in the case of saned, corrupts the network protocol. Here's an example: # chmod 700 /root # su -c 'whoami' saned bash: /root/.bashrc: Permission denied saned # chmod 755 /root # su -c 'whoami' saned saned > Try "exec /usr/sbin/saned 2> saned.$$.stderr" only. Cool! This is what I needed. I now get logging info on the server which says that /dev/usb/scanner0 cannot be accessed (permission denied). I did a "chmod o+rw /dev/usb/scanner0" and now saned daemon works under user saned! The last mystery is why the user saned was unable to access /dev/usb/scanner0. The problem was in xinetd. The relevant data is as follows: # ls -l /dev/usb/scanner0 crw-rw---- 1 robert scanner 180, 48 Apr 11 07:25 /dev/usb/scanner0 # grep scanner /etc/group scanner:x:507:saned # grep saned /etc/passwd saned:x:506:506::/home/saned:/bin/bash # su -c 'groups' saned saned scanner I added the line "groups > foo" into the /usr/sbin/saned2 script in order to see what permissions the saned daemon had when run. The result was that the saned daemon only belonged to the group saned not the groups "saned scanner". The reason for this is that xinetd strips all group information from a user before it runs a daemon. Since I had the lines "user = saned" and "group = saned" the _only_ group that saned belonged to was the saned group. xinetd does not allow multiple groups to be specified in the configuration file. The way to fix this problem is to add the line "groups = yes" to prevent xinetd from stripping group information from the daemon process. Thanks for your help everyone! Robert.