gnc-backend-file.c: ERR_BACKEND_PERM too unspecific

[Tim Wunder]

OK, I know I'm not qualified to have a legitimate opinion on this, but can you 
answer a stupid question for me?
As I understand the process, gnucash renames the existing file, then creates a 
new file of the same name, then chowns it to whatever the permissions of the 
original file was. This seems really odd to me.
Why is a new data file created at all? Why isn't the original data file simply 
copied (like a cp -a) to the backup file. Let the O/S deal with permissions. 
Derek's suggestion to not chown at all and "forego the group setting 
completely and assume the user has a proper setgid setting on the directory" 
seems reasonable to me.

Regards, 
Tim

On Monday 05 December 2005 4:33 pm, someone claiming to be Christian Stimming 
wrote:
> Ok, as you can see from the ChangeLog: We chown() now only for the group
> id, no longer for the user id. Also, an error here is only a warning, not
> an error.
>
> There's still the open question about the severity when the chmod() fails.
> Right now this is presented as a fatal error to the user, although the
> "save" completed successfully already at that point. We should do something
> about this, too ...
>
> My earlier statement wasn't fully correct; the chmod/chown is performed on
> the newly created file, not on the archived file. Both may have their
> reasons, but a failure in one of them is a different thing than a failure
> in the "save file" action. We need a different error code and error message
> for those cases, and currently we don't have it.
>
> Christian
>
> Am Dienstag, 29. November 2005 16:37 schrieb Derek Atkins:
> > What I don't understand is why we're trying to chown() the
> > file:
> >
> > [warlord at cliodev src]$ find . -name \*.c | xargs grep chown
> > ./src/backend/file/gnc-backend-file.c:            if(chown(tmp_name,
> > statbuf.st_uid, statbuf.st_gid) != 0)
> > ./src/backend/file/gnc-backend-file.c:                PWARN("unable to
> > chown filename %s: %s", ./src/backend/file/gnc-backend-file.c:#if
> > VFAT_DOESNT_SUCK /* chown always fails on vfat fs */
> >
> > I think we're trying to retain the original owner/group, but that
> > can't work because only the superuser can change the owner.  I think
> > we should change this chown() call to:
> >
> >   chown(tmp_name, -1, statbuf.st_gid)
> >
> > This would retain the original group setting on the file, which should
> > work provided the user is in the group.  Or we can just forego the
> > group setting completely and assume the user has a proper setgid
> > setting on the directory.
> >
> > -derek
> >
> > Tim Wunder <tim at thewunders.org> writes:
> > > I don't see where Christian is talking about chmoding a backup file
> > > here. I read this as him getting a warning when saving the data file. A
> > > warning that caused the app to fail, and really wasn't the warning it
> > > thought it was (the file was saved regardless of the warning).
> > > Regardless, an app should not try to chmod *any* pre-existing data
> > > file. Sys admins assign file permissions for a reason. Apps shouldn't
> > > attempt to change that willy-nilly...
> > >
> > > Of course, I reserve the right to have misread what he wrote ;)
> > >
> > > Tim
> > >
> > > On Monday 28 November 2005 6:48 pm, someone claiming to be Derek Atkins
>
> wrote:
> > >> I'm wondering why we even try to chown the old backup file at all?
> > >> I can understand why we want to chmod the NEW data file, but I
> > >> don't understand why we'd want to do anything but "rename" the
> > >> old backup file?
> > >>
> > >> -derek
> > >>
> > >> Christian Stimming <stimming at tuhh.de> writes:
> > >> > I just recently got a new error message from the gnucash-HEAD that
> > >> > didn't show up with 1.8. Here's the deal: I have two linux users
> > >> > accessing the gnucash file alternating. The directory of that file
> > >> > has 775 permissions and both of them are in the same group, so both
> > >> > are able to write the file in that directory.  However, on file
> > >> > saving in 1.8 I always got the PWARN message on the cmdline saying
> > >> > that the new user is "unable to chown filename", which was quite
> > >> > understandable because the new user cannot chown the previous file
> > >> > that was written by the old user. In 1.8 this was a not-too-noisy
> > >> > warning on the cmdline.
> > >> >
> > >> > However, with SVN-HEAD on "save file" this "unable to chown
> > >> > filename" warning in  src/backend/file/gnc-backend-file.c:556
> > >> > results in a ERR_BACKEND_PERM error code being passed to gnucash,
> > >> > which will then show a big red error window saying "You do not have
> > >> > permission to access %s\n"! Uh oh! Very frightening.
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20051205/00161db0/attachment.bin