gnc-backend-file.c: ERR_BACKEND_PERM too unspecific

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

gnc-backend-file.c: ERR_BACKEND_PERM too unspecific

Christian Stimming
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.

As it turns out, the file saving went just fine. Only the old backup file
couldn't be chown'd to the new user, because it is still being owned by that
other user.

Conclusion: This ERR_BACKEND_PERM either needs to be removed from these two
particular warnings, or these particular warnings need to have (new,
additional) error codes. That ERR_BACKEND_PERM error message is really meant
for the case when the actual data file cannot be accessed because of
permissions, isn't it? This user feedback needs to be crystal clear in such
respect. Any ideas?

Christian
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: gnc-backend-file.c: ERR_BACKEND_PERM too unspecific

Derek Atkins
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 <[hidden email]> 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.
>
> As it turns out, the file saving went just fine. Only the old backup file
> couldn't be chown'd to the new user, because it is still being owned by that
> other user.
>
> Conclusion: This ERR_BACKEND_PERM either needs to be removed from these two
> particular warnings, or these particular warnings need to have (new,
> additional) error codes. That ERR_BACKEND_PERM error message is really meant
> for the case when the actual data file cannot be accessed because of
> permissions, isn't it? This user feedback needs to be crystal clear in such
> respect. Any ideas?
>
> Christian
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: gnc-backend-file.c: ERR_BACKEND_PERM too unspecific

Tim Wunder (Lists)
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 <[hidden email]> 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.
> >
> > As it turns out, the file saving went just fine. Only the old backup file
> > couldn't be chown'd to the new user, because it is still being owned by
> > that other user.
> >
> > Conclusion: This ERR_BACKEND_PERM either needs to be removed from these
> > two particular warnings, or these particular warnings need to have (new,
> > additional) error codes. That ERR_BACKEND_PERM error message is really
> > meant for the case when the actual data file cannot be accessed because
> > of permissions, isn't it? This user feedback needs to be crystal clear in
> > such respect. Any ideas?
> >
> > Christian
> > _______________________________________________
> > gnucash-devel mailing list
> > [hidden email]
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
--
Fedora Core release 4 (Stentz), Linux 2.6.14-1.1637_FC4
KDE: 3.4.3-1.1.fc4.kde, xorg-x11-6.8.2-37.FC4.49.2
 19:30:06 up 8 days, 11:48,  4 users,  load average: 1.58, 1.32, 0.67
MP3/OGG archive Total playlength : 7 days, 10 hours, 31 mins 30 seconds
"It's what you learn after you know it all that counts" John Wooden

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: gnc-backend-file.c: ERR_BACKEND_PERM too unspecific

Derek Atkins
I think you misread what he (and I) wrote..  ;)

Gnucash does a "rename and create" when saving the data file.
It renames the existing data file to the backup file, then creates
a new file and saves the new data into it.  Then it tries to
fix up the permissions on the new data file (chmod).

What I don't understand is why we're trying to chown() the
file:

[warlord@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 <[hidden email]> 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 <[hidden email]> 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.
>> >
>> > As it turns out, the file saving went just fine. Only the old backup file
>> > couldn't be chown'd to the new user, because it is still being owned by
>> > that other user.
>> >
>> > Conclusion: This ERR_BACKEND_PERM either needs to be removed from these
>> > two particular warnings, or these particular warnings need to have (new,
>> > additional) error codes. That ERR_BACKEND_PERM error message is really
>> > meant for the case when the actual data file cannot be accessed because
>> > of permissions, isn't it? This user feedback needs to be crystal clear in
>> > such respect. Any ideas?
>> >
>> > Christian
>> > _______________________________________________
>> > gnucash-devel mailing list
>> > [hidden email]
>> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
> --
> Fedora Core release 4 (Stentz), Linux 2.6.14-1.1637_FC4
> KDE: 3.4.3-1.1.fc4.kde, xorg-x11-6.8.2-37.FC4.49.2
>  19:30:06 up 8 days, 11:48,  4 users,  load average: 1.58, 1.32, 0.67
> MP3/OGG archive Total playlength : 7 days, 10 hours, 31 mins 30 seconds
> "It's what you learn after you know it all that counts" John Wooden
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: gnc-backend-file.c: ERR_BACKEND_PERM too unspecific

Christian Stimming
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@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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: gnc-backend-file.c: ERR_BACKEND_PERM too unspecific

Tim Wunder (Lists)
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@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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: gnc-backend-file.c: ERR_BACKEND_PERM too unspecific

Derek Atkins
Quoting Tim Wunder <[hidden email]>:

> 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.

It's not odd at all.  LOTS of programs do this.  emacs does this,
for example.  It will rename() the old file to the tilde-file,
and then create the new file and write your new data to it.  Then
it reverts the file permissions to the original version.

> 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.

"cp" is a command-line utility.  There is no "cp" API function.

>    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.

You're confusing chown() and chmod().
chown() changes ownership.  chmod changes the mode permissions.

> Regards,
> Tim

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: gnc-backend-file.c: ERR_BACKEND_PERM too unspecific

Tim Wunder (Lists)
On Monday 05 December 2005 5:11 pm, someone claiming to be Derek Atkins wrote:

> Quoting Tim Wunder <[hidden email]>:
> > 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.
>
> It's not odd at all.  LOTS of programs do this.  emacs does this,
> for example.  It will rename() the old file to the tilde-file,
> and then create the new file and write your new data to it.  Then
> it reverts the file permissions to the original version.
>
OK. But does it try to chown the new file? This still seems to be a function
for the O/S, and the permissions on the directory. It seems to me that an app
shouldn't be concerned with file ownership when creating a file.

> > 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.
>
> "cp" is a command-line utility.  There is no "cp" API function.
>

Well, that's a good reason not to copy the file, I guess.

> >    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.
>
> You're confusing chown() and chmod().
> chown() changes ownership.  chmod changes the mode permissions.
>

Well, it might seem so by what I typed (I did type "permissions" when I
shoulda typed "ownership"), but rest assured, I know the difference between
chown and chmod.

Regards,
Tim

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: gnc-backend-file.c: ERR_BACKEND_PERM too unspecific

Derek Atkins
Tim Wunder <[hidden email]> writes:

> OK. But does it try to chown the new file? This still seems to be a
> function for the O/S, and the permissions on the directory. It seems
> to me that an app shouldn't be concerned with file ownership when
> creating a file.

Yes and no.  Yes it runs chown() but it's not trying to change the
OWNER, only the GROUP.  This should be perfectly safe, and it's
something that other apps do too.

-derek
--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: gnc-backend-file.c: ERR_BACKEND_PERM too unspecific

Karl Hegbloom
In reply to this post by Derek Atkins
On Mon, 2005-12-05 at 17:11 -0500, Derek Atkins wrote:
> Quoting Tim Wunder <[hidden email]>:
> > 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.

"chowns it to whatever owner and group", and "chmod to set the
permission mode".

> It's not odd at all.  LOTS of programs do this.  Emacs does this,
> for example.  It will rename() the old file to the tilde-file,
> and then create the new file and write your new data to it.  Then
> it reverts the file permissions to the original version.

Emacs has a setting for 'backup by copying'.  This is useful if you need
to edit files that have more than one directory entry, or hard link, and
you _do_ _not_ want the hard-link broken by edit/save.

On the Linux file system, the files data location, size, ownership and
permissions are specified by it's "inode" (See:
http://en.wikipedia.org/wiki/Inode).  The directory entries specify the
file name and which inode contains the file information.  More than one
directory entry can point to a particular inode, and the inode contains
a link count which tells how many directory entries point to that file.
The unlink() (man unlink) system call removes a directory entry and
decrements the link count in the inode.  When it reaches zero, the
blocks consumed by that file are freed for reuse by the file system.
When a file is opened (man open) the link count is incremented, and when
it's closed (man close) the link count is decremented.  That is why you
can open a file, unlink it, and keep using it, even though there is no
longer a directory entry referring to it.  When the invisible file is
closed, its blocks will be released.

If you use the rename() (man rename, and man mv) system call, it changes
the file name in the directory entry.  If you then open a new file using
the original file's old name, the operating system creates a brand new
inode for that file.  Thus, the old name no longer points to the same
file that other directory entries still point to, aka, hard links to
that file are broken.  (Symbolic links to that file are not broken,
since they point to the file by _name_, rather than by _inode_.)

In my experience, hard links are not used very often, except in cases
where you actually do want to break the link if you change the file in
one location.  Perhaps you have a tree of source code, and you then make
a tree of hard links to it.  The new tree won't take up more space,
since the directory entries point to the same inodes as the ones in the
original tree.  If you want to edit a file in the new tree without
affecting the original file, you must rename the file, then make a copy
of it under the original name, and edit that.  If you want the edit to
show up in both places, you must ensure that Emacs is set to 'backup by
copying' mode.  (What does 'vim' do here?)

Since the ownership, permissions and POSIX ACL attributes (man acl) are
all associated with the inode rather than the directory entry, when you
rename the old file to a new name then open a new file under the old
name, you must then set the ownership and permissions of the newly
created inode.  In the POSIX API, that is done with separate system
calls --- it is not part of open().

Since the only system call guaranteed to be atomic over NFS is rename(),
if there are concurrent file access issues, it may be that special care
must be taken to ensure that two processes on separate computers do not
race for access to the file.  You can read about that by researching
Debian Policy regarding mail spool file locking on NFS.  ;-)

If there are security issues, like a race to access and open this new
file before it's permissions are set, then the file should be kept in a
secure sub-directory where only the appropriate users may access any
files created there.

Also see: man ln, man 2 stat

> > 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.
>
> "cp" is a command-line utility.  There is no "cp" API function.

You may like to get a copy of the GNU Shellutils source, and have a look
at what 'cp' actually does.  Another one to look at is the 'cp' in
Busybox; it's a little simpler, but does basically the same thing.

> > 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.

There may be cases where that assumption is not correct, I think.  For
the general case, and to err on the side of caution, it's probably best
to set all of owner, group, mode, and ACL attributes.  If ACL is not
being dealt with by the application, and the administrator wants to use
them, then I suppose they can be set for the directory...?

--
Karl Hegbloom <[hidden email]>

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: gnc-backend-file.c: ERR_BACKEND_PERM too unspecific

Derek Atkins
Karl Hegbloom <[hidden email]> writes:

> There may be cases where that assumption is not correct, I think.  For
> the general case, and to err on the side of caution, it's probably best
> to set all of owner, group, mode, and ACL attributes.  If ACL is not
> being dealt with by the application, and the administrator wants to use
> them, then I suppose they can be set for the directory...?

chown() requires root permissions.  You cannot set the owner from a
non-suid program.  Gnucash is not setuid (and shouldn't be setuid!),
so we cannot chown() the file.  We can still chgrp the file, and we
do so now.

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel