> > Hmmm. It is probably better to run that way, but I still don't > > understand why the previous setup didn't work unless there > > was something wrong with the gid bacula or it didn't actually > > get added to the disk group. > > I think it is because the drop() function calls setgroups() with the > selected gid, so even if the bacula user is a member of the disk > group in /etc/group, the process is not in that group. At least I > think that's what setgroups() does. The members listed in > /etc/group only affect callers of the initgroups() function, such > as login or su. > I must admit I really don't know for sure how these things work. But I assumed that since the process accessing the tape was running with uid bacula, and _user_ bacula belongs to group disk (/etc/group), that process should have been able to access the tape drive that had rw permissions for group disk. I've been thinking these rights would have been checked just at the time the process accesses the device.
So, the way how I thought it was that the gid of the process even wasn't supposed to affect to anything. But this might have been a wrong idea from me. -- TiN ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
