|
From: Martin S. <ma...@li...> - 2010-12-30 18:33:10
|
>>>>> On Wed, 29 Dec 2010 19:22:55 -0700, Devin Reade said: > > Martin Simmons <ma...@li...> wrote: > > > I read that glusterfs uses FUSE, so it might be checking something more than > > the uid. That would explain why a root shell can access the files. Note that > > the error is "Operation not permitted", which is different from the normal > > "Permission denied" error you get from files made unreadable by chmod. > > > > Can you try running bacula-fd without passing the -u and -g arguments at all? > > That is slightly different from passing -u root -g bacula. > > It took me a few days to get back to this as I was out of town. > > After a bit of experimenting, I determined that the -u root has > no impact on the situation, but elimination of the -g bacula > allows the files on the glusterfs filesystem to be backed up > (where they exist in a home directory having mode 0700). > > For the moment, I've eliminated -g bacula from the daemon args. > > I must say, though, that that is really weird. If running as root > is sufficient to access it, I wouldn't expect running with the bacula > group ID to block access. Do you have any idea of the mechanism > here? No, I don't know. My guess is that it FUSE or glusterfs checks for gid root as well as uid root. > Googling with various terms didn't show anything enlightening, > although I'm not sure if > <http://sourceforge.net/apps/mediawiki/fuse/index.php?title=FAQ#Why_does_cp_return_operation_not_permitted_when_copying_a_file_with_no_write_permissions_for_the_owner.3F> > might be relevent. No, because that is about how cp opens the destination file for writing. Bacula doesn't open files with O_CREAT when it is doing a backup. __Martin |