GNU bug report logs -
#74400
31.0.50; tramp-loaddefs.elc suddenly owned by root
Previous Next
Reported by: Michael Heerdegen <michael_heerdegen <at> web.de>
Date: Sun, 17 Nov 2024 16:17:01 UTC
Severity: wishlist
Found in version 31.0.50
Fixed in version 30.1
Done: Michael Albinus <michael.albinus <at> gmx.de>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 74400 in the body.
You can then email your comments to 74400 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
michael.albinus <at> gmx.de, bug-gnu-emacs <at> gnu.org
:
bug#74400
; Package
emacs
.
(Sun, 17 Nov 2024 16:17:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Michael Heerdegen <michael_heerdegen <at> web.de>
:
New bug report received and forwarded. Copy sent to
michael.albinus <at> gmx.de, bug-gnu-emacs <at> gnu.org
.
(Sun, 17 Nov 2024 16:17:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello to everybody,
one of my last make + make-install calls in the last couple of days
again made a file in my home directory being owned by root:
| /home/micha/software/emacs/lisp/net:
| drwxr-xr-x 2 micha micha 4,0K Nov 16 17:03 .
| drwxr-xr-x 28 micha micha 20K Nov 16 17:03 ..
| [...]
| -rw-rw-r-- 1 micha micha 108K Nov 15 17:01 tramp-loaddefs.el
| -rw-r--r-- 1 root root 120K Nov 15 17:01 tramp-loaddefs.elc
Does that ring a bell (Michael maybe)? Can we maybe prevent this?
TIA,
Michael
In GNU Emacs 31.0.50 (build 24, x86_64-pc-linux-gnu, cairo version
1.16.0) of 2024-11-16 built on drachen
Repository revision: 88c6b20cf609cb0b53d1a8ea9db0c35ba77fadb9
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Debian GNU/Linux 12 (bookworm)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74400
; Package
emacs
.
(Sun, 17 Nov 2024 16:35:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 74400 <at> debbugs.gnu.org (full text, mbox):
> Cc: Michael Albinus <michael.albinus <at> gmx.de>
> Date: Sun, 17 Nov 2024 17:17:37 +0100
> From: Michael Heerdegen via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> one of my last make + make-install calls in the last couple of days
> again made a file in my home directory being owned by root:
>
> | /home/micha/software/emacs/lisp/net:
> | drwxr-xr-x 2 micha micha 4,0K Nov 16 17:03 .
> | drwxr-xr-x 28 micha micha 20K Nov 16 17:03 ..
> | [...]
> | -rw-rw-r-- 1 micha micha 108K Nov 15 17:01 tramp-loaddefs.el
> | -rw-r--r-- 1 root root 120K Nov 15 17:01 tramp-loaddefs.elc
>
> Does that ring a bell (Michael maybe)? Can we maybe prevent this?
Judging by the name of the directory you show, this is not the
installation tree, but a build tree, right? Then it doesn't
necessarily have anything to do with "make install", but with how you
run "make", I guess? because tramp-loaddefs.elc is produced by
"make", not by "make install".
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74400
; Package
emacs
.
(Sun, 17 Nov 2024 17:03:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 74400 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Judging by the name of the directory you show, this is not the
> installation tree, but a build tree, right?
Yes.
> Then it doesn't necessarily have anything to do with "make install",
> but with how you run "make", I guess? because tramp-loaddefs.elc is
> produced by "make", not by "make install".
I don't have an explanation. But AFAIR I did not call "make" as user
"root", I am very careful to avoid doing that by accident because I have
to clean up a mess afterwards when that happens.
"tramp-loaddefs.elc" is the only file owned by root - which would mean
that the problematic "make" call would have had compiled only one single
file (unlikely). I would estimate a probability of 75% that this was
not my fault.
I didn't find something like "sudo make" in my bash history either, and
I did not do something like sudo su in the last days.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74400
; Package
emacs
.
(Sun, 17 Nov 2024 17:48:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 74400 <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
Hi Michael,
> I didn't find something like "sudo make" in my bash history either, and
> I did not do something like sudo su in the last days.
I tried to reproduce, and I've applied
--8<---------------cut here---------------start------------->8---
# make bootstrap
# sudo make install
# ll lisp/net/*loaddefs*
-rw-rw----+ 1 albinus albinus 110234 Nov 17 17:37 lisp/net/tramp-loaddefs.el
-rw-r--r--+ 1 albinus albinus 122088 Nov 17 17:58 lisp/net/tramp-loaddefs.elc
--8<---------------cut here---------------end--------------->8---
This is inside the git repo. No idea, what happened for you.
You have shown
--8<---------------cut here---------------start------------->8---
| -rw-rw-r-- 1 micha micha 108K Nov 15 17:01 tramp-loaddefs.el
| -rw-r--r-- 1 root root 120K Nov 15 17:01 tramp-loaddefs.elc
--8<---------------cut here---------------end--------------->8---
Do you know (from bash history or whatever), which command did run at
that time? Perhaps also check bash history of user root?
> Michael.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74400
; Package
emacs
.
(Sun, 17 Nov 2024 18:23:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 74400 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> I tried to reproduce, and I've applied
>
> # make bootstrap
> # sudo make install
> # ll lisp/net/*loaddefs*
> -rw-rw----+ 1 albinus albinus 110234 Nov 17 17:37 lisp/net/tramp-loaddefs.el
> -rw-r--r--+ 1 albinus albinus 122088 Nov 17 17:58 lisp/net/tramp-loaddefs.elc
>
> This is inside the git repo. No idea, what happened for you.
I also can't reproduce this now.
> You have shown
>
> | -rw-rw-r-- 1 micha micha 108K Nov 15 17:01 tramp-loaddefs.el
> | -rw-r--r-- 1 root root 120K Nov 15 17:01 tramp-loaddefs.elc
>
> Do you know (from bash history or whatever), which command did run at
> that time? Perhaps also check bash history of user root?
I didn't find anything obvious apart from the daily make -j4 plus sudo
make install. I'm quite sure I did not use a root shell or root Emacs
two days ago.
I try to recover everything I can find in my memory. If I don't find
something, let's assume a pilot error, although I have no idea how I
could have caused this by myself.
Michael.
Reply sent
to
Michael Heerdegen <michael_heerdegen <at> web.de>
:
You have taken responsibility.
(Mon, 18 Nov 2024 01:57:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Michael Heerdegen <michael_heerdegen <at> web.de>
:
bug acknowledged by developer.
(Mon, 18 Nov 2024 01:57:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 74400-done <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
> I try to recover everything I can find in my memory.
No idea to be honest. Let's not waste time and assume I made nonsense.
I can reopen in case it comes back.
Michael.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 18 Nov 2024 08:39:01 GMT)
Full text and
rfc822 format available.
Reply sent
to
Michael Albinus <michael.albinus <at> gmx.de>
:
You have taken responsibility.
(Mon, 18 Nov 2024 08:39:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Michael Heerdegen <michael_heerdegen <at> web.de>
:
bug acknowledged by developer.
(Mon, 18 Nov 2024 08:39:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 74400-done <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
Hi Michael,
>> I try to recover everything I can find in my memory.
>
> No idea to be honest. Let's not waste time and assume I made nonsense.
> I can reopen in case it comes back.
Wait, I could reproduce the problem:
--8<---------------cut here---------------start------------->8---
# rm lisp/net/tramp-loaddefs.elc
# sudo make install
# ll lisp/net/*loaddefs*
-rw-rw----+ 1 albinus albinus 110234 Nov 17 17:37 lisp/net/tramp-loaddefs.el
-rw-r--r--+ 1 root root 122088 Nov 18 09:27 lisp/net/tramp-loaddefs.elc
--8<---------------cut here---------------end--------------->8---
I'll reopen the bug.
> Michael.
Best regards, Michael.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 18 Nov 2024 08:43:01 GMT)
Full text and
rfc822 format available.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Mon, 18 Nov 2024 12:50:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Michael Heerdegen <michael_heerdegen <at> web.de>
:
bug acknowledged by developer.
(Mon, 18 Nov 2024 12:50:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 74400-done <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 74400-done <at> debbugs.gnu.org
> Date: Mon, 18 Nov 2024 09:37:51 +0100
>
> Michael Heerdegen <michael_heerdegen <at> web.de> writes:
>
> Hi Michael,
>
> >> I try to recover everything I can find in my memory.
> >
> > No idea to be honest. Let's not waste time and assume I made nonsense.
> > I can reopen in case it comes back.
>
> Wait, I could reproduce the problem:
>
> --8<---------------cut here---------------start------------->8---
> # rm lisp/net/tramp-loaddefs.elc
> # sudo make install
> # ll lisp/net/*loaddefs*
> -rw-rw----+ 1 albinus albinus 110234 Nov 17 17:37 lisp/net/tramp-loaddefs.el
> -rw-r--r--+ 1 root root 122088 Nov 18 09:27 lisp/net/tramp-loaddefs.elc
> --8<---------------cut here---------------end--------------->8---
But note that here the time stamps of the two files are very diferent,
which seems to indicate that tramp-loaddefs.el was somehow
byte-compiled as part of "make install". Whereas in the OP, we saw a
different picture:
| /home/micha/software/emacs/lisp/net:
| drwxr-xr-x 2 micha micha 4,0K Nov 16 17:03 .
| drwxr-xr-x 28 micha micha 20K Nov 16 17:03 ..
| [...]
| -rw-rw-r-- 1 micha micha 108K Nov 15 17:01 tramp-loaddefs.el
| -rw-r--r-- 1 root root 120K Nov 15 17:01 tramp-loaddefs.elc
Look, ma: same time stamp. Which seems to indicate they were both
produced at the same time, so probably by the same command.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 18 Nov 2024 13:03:01 GMT)
Full text and
rfc822 format available.
Reply sent
to
Michael Albinus <michael.albinus <at> gmx.de>
:
You have taken responsibility.
(Tue, 19 Nov 2024 09:10:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Michael Heerdegen <michael_heerdegen <at> web.de>
:
bug acknowledged by developer.
(Tue, 19 Nov 2024 09:10:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 74400-done <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> > No idea to be honest. Let's not waste time and assume I made nonsense.
>> > I can reopen in case it comes back.
>>
>> Wait, I could reproduce the problem:
>>
>> --8<---------------cut here---------------start------------->8---
>> # rm lisp/net/tramp-loaddefs.elc
>> # sudo make install
>> # ll lisp/net/*loaddefs*
>> -rw-rw----+ 1 albinus albinus 110234 Nov 17 17:37 lisp/net/tramp-loaddefs.el
>> -rw-r--r--+ 1 root root 122088 Nov 18 09:27 lisp/net/tramp-loaddefs.elc
>> --8<---------------cut here---------------end--------------->8---
>
> But note that here the time stamps of the two files are very diferent,
> which seems to indicate that tramp-loaddefs.el was somehow
> byte-compiled as part of "make install". Whereas in the OP, we saw a
> different picture:
>
> | /home/micha/software/emacs/lisp/net:
> | drwxr-xr-x 2 micha micha 4,0K Nov 16 17:03 .
> | drwxr-xr-x 28 micha micha 20K Nov 16 17:03 ..
> | [...]
> | -rw-rw-r-- 1 micha micha 108K Nov 15 17:01 tramp-loaddefs.el
> | -rw-r--r-- 1 root root 120K Nov 15 17:01 tramp-loaddefs.elc
>
> Look, ma: same time stamp. Which seems to indicate they were both
> produced at the same time, so probably by the same command.
My example doesn't claim to be the recipe which happened to Michael. But
it shows, that 'sudo make install' could create root-owned files in the
build dir, and that's what this bug report is about.
I don't know whether it is important enough to change something. But we
should know (and document), that it could happen.
Best regards, Michael.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 19 Nov 2024 09:12:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74400
; Package
emacs
.
(Tue, 19 Nov 2024 15:55:01 GMT)
Full text and
rfc822 format available.
Message #48 received at 74400 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: michael_heerdegen <at> web.de, 74400-done <at> debbugs.gnu.org
> Date: Tue, 19 Nov 2024 10:09:20 +0100
>
> My example doesn't claim to be the recipe which happened to Michael. But
> it shows, that 'sudo make install' could create root-owned files in the
> build dir, and that's what this bug report is about.
>
> I don't know whether it is important enough to change something. But we
> should know (and document), that it could happen.
If it's important enough, maybe.
I think "make install" uses chmod to give everyone access to the file
because some files could be owned by root. If that works, why is the
ownership important?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74400
; Package
emacs
.
(Thu, 02 Jan 2025 02:01:02 GMT)
Full text and
rfc822 format available.
Message #51 received at 74400 <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
> Michael Albinus <michael.albinus <at> gmx.de> writes:
>
>> I tried to reproduce, and I've applied
>>
>> # make bootstrap
>> # sudo make install
>> # ll lisp/net/*loaddefs*
>> -rw-rw----+ 1 albinus albinus 110234 Nov 17 17:37 lisp/net/tramp-loaddefs.el
>> -rw-r--r--+ 1 albinus albinus 122088 Nov 17 17:58 lisp/net/tramp-loaddefs.elc
>>
>> This is inside the git repo. No idea, what happened for you.
>
> I also can't reproduce this now.
>
>
>> You have shown
>>
>> | -rw-rw-r-- 1 micha micha 108K Nov 15 17:01 tramp-loaddefs.el
>> | -rw-r--r-- 1 root root 120K Nov 15 17:01 tramp-loaddefs.elc
>>
>> Do you know (from bash history or whatever), which command did run at
>> that time? Perhaps also check bash history of user root?
>
> I didn't find anything obvious apart from the daily make -j4 plus sudo
> make install. I'm quite sure I did not use a root shell or root Emacs
> two days ago.
>
> I try to recover everything I can find in my memory. If I don't find
> something, let's assume a pilot error, although I have no idea how I
> could have caused this by myself.
Did you make any progress here, or should the bug be closed?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74400
; Package
emacs
.
(Thu, 02 Jan 2025 15:36:01 GMT)
Full text and
rfc822 format available.
Message #54 received at 74400 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
> Did you make any progress here, or should the bug be closed?
Michael Albinus wanted to do something about this issue as far as I
understood. I really would appreciate if this would be fixed.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74400
; Package
emacs
.
(Thu, 02 Jan 2025 15:42:01 GMT)
Full text and
rfc822 format available.
Message #57 received at 74400 <at> debbugs.gnu.org (full text, mbox):
severity 74400 wishlist
thanks
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
> Stefan Kangas <stefankangas <at> gmail.com> writes:
>
>> Did you make any progress here, or should the bug be closed?
>
> Michael Albinus wanted to do something about this issue as far as I
> understood. I really would appreciate if this would be fixed.
Ah, right, I see that now. Yes, it would be good to fix this.
I'm tagging it as wishlist for now.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74400
; Package
emacs
.
(Thu, 02 Jan 2025 15:42:02 GMT)
Full text and
rfc822 format available.
Message #60 received at 74400 <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
Hi Michael,
> Michael Albinus wanted to do something about this issue as far as I
> understood. I really would appreciate if this would be fixed.
I'm not aware of this. There was only one contribution from my side to
this bug, with Message-ID <875xol92h1.fsf <at> gmx.de>.
> Michael.
Best reegards, michael.
Severity set to 'wishlist' from 'normal'
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Thu, 02 Jan 2025 15:42:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74400
; Package
emacs
.
(Thu, 02 Jan 2025 17:14:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 74400 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> I'm not aware of this. There was only one contribution from my side to
> this bug, with Message-ID <875xol92h1.fsf <at> gmx.de>.
No, we had continued the discussion on Nov 19th, with
"74400-done <at> debbugs.gnu.org" in CC. But it seems these messages have
not been archived. Do you have them?
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74400
; Package
emacs
.
(Thu, 02 Jan 2025 17:26:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 74400 <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
Hi Michael,
>> I'm not aware of this. There was only one contribution from my side to
>> this bug, with Message-ID <875xol92h1.fsf <at> gmx.de>.
>
> No, we had continued the discussion on Nov 19th, with
> "74400-done <at> debbugs.gnu.org" in CC. But it seems these messages have
> not been archived. Do you have them?
Ah, yes. I've found another message from me (Message-ID
<877c8z8u9r.fsf <at> gmx.de>), where I said
| My example doesn't claim to be the recipe which happened to Michael. But
| it shows, that 'sudo make install' could create root-owned files in the
| build dir, and that's what this bug report is about.
|
| I don't know whether it is important enough to change something. But we
| should know (and document), that it could happen.
Strange, that it wasn't added to the bug's messages.
Anyway, I kep it on my todo. Perhaps I find something useful to write
next days.
> Michael.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74400
; Package
emacs
.
(Thu, 02 Jan 2025 17:43:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 74400 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> Anyway, I kep it on my todo. Perhaps I find something useful to write
> next days.
Ok - thank you.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74400
; Package
emacs
.
(Thu, 02 Jan 2025 20:14:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 74400 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Michael Albinus <michael.albinus <at> gmx.de>
>> Cc: michael_heerdegen <at> web.de, 74400-done <at> debbugs.gnu.org
>> Date: Tue, 19 Nov 2024 10:09:20 +0100
>>
>> My example doesn't claim to be the recipe which happened to Michael. But
>> it shows, that 'sudo make install' could create root-owned files in the
>> build dir, and that's what this bug report is about.
>>
>> I don't know whether it is important enough to change something. But we
>> should know (and document), that it could happen.
>
> If it's important enough, maybe.
>
> I think "make install" uses chmod to give everyone access to the file
> because some files could be owned by root. If that works, why is the
> ownership important?
Does everyone get write rights, though? If not, how can you run
commands like "git clean -fxd" as a regular root after "make install"?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74400
; Package
emacs
.
(Thu, 02 Jan 2025 21:06:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 74400 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Thu, 2 Jan 2025 14:13:31 -0600
> Cc: michael_heerdegen <at> web.de, 74400 <at> debbugs.gnu.org
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Michael Albinus <michael.albinus <at> gmx.de>
> >> Cc: michael_heerdegen <at> web.de, 74400-done <at> debbugs.gnu.org
> >> Date: Tue, 19 Nov 2024 10:09:20 +0100
> >>
> >> My example doesn't claim to be the recipe which happened to Michael. But
> >> it shows, that 'sudo make install' could create root-owned files in the
> >> build dir, and that's what this bug report is about.
> >>
> >> I don't know whether it is important enough to change something. But we
> >> should know (and document), that it could happen.
> >
> > If it's important enough, maybe.
> >
> > I think "make install" uses chmod to give everyone access to the file
> > because some files could be owned by root. If that works, why is the
> > ownership important?
>
> Does everyone get write rights, though? If not, how can you run
> commands like "git clean -fxd" as a regular root after "make install"?
Sorry, I don't follow: "make install" writes to the installation
directory, and invokes chmod on the files installed there, whereas
"git clean -fxd" is run on the Git repository, which is a different
directory entirely. What am I missing?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74400
; Package
emacs
.
(Thu, 02 Jan 2025 21:21:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 74400 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Thu, 2 Jan 2025 14:13:31 -0600
>> Cc: michael_heerdegen <at> web.de, 74400 <at> debbugs.gnu.org
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> From: Michael Albinus <michael.albinus <at> gmx.de>
>> >> Cc: michael_heerdegen <at> web.de, 74400-done <at> debbugs.gnu.org
>> >> Date: Tue, 19 Nov 2024 10:09:20 +0100
>> >>
>> >> My example doesn't claim to be the recipe which happened to Michael. But
>> >> it shows, that 'sudo make install' could create root-owned files in the
>> >> build dir, and that's what this bug report is about.
>> >>
>> >> I don't know whether it is important enough to change something. But we
>> >> should know (and document), that it could happen.
>> >
>> > If it's important enough, maybe.
>> >
>> > I think "make install" uses chmod to give everyone access to the file
>> > because some files could be owned by root. If that works, why is the
>> > ownership important?
>>
>> Does everyone get write rights, though? If not, how can you run
>> commands like "git clean -fxd" as a regular root after "make install"?
>
> Sorry, I don't follow: "make install" writes to the installation
> directory, and invokes chmod on the files installed there, whereas
> "git clean -fxd" is run on the Git repository, which is a different
> directory entirely. What am I missing?
AFAIU, the issue here is that "sudo make install" can create root-owned
files in the build directory.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74400
; Package
emacs
.
(Fri, 03 Jan 2025 07:56:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 74400 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Thu, 2 Jan 2025 15:20:11 -0600
> Cc: michael.albinus <at> gmx.de, michael_heerdegen <at> web.de, 74400 <at> debbugs.gnu.org
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Stefan Kangas <stefankangas <at> gmail.com>
> >> Date: Thu, 2 Jan 2025 14:13:31 -0600
> >> Cc: michael_heerdegen <at> web.de, 74400 <at> debbugs.gnu.org
> >>
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>
> >> >> From: Michael Albinus <michael.albinus <at> gmx.de>
> >> >> Cc: michael_heerdegen <at> web.de, 74400-done <at> debbugs.gnu.org
> >> >> Date: Tue, 19 Nov 2024 10:09:20 +0100
> >> >>
> >> >> My example doesn't claim to be the recipe which happened to Michael. But
> >> >> it shows, that 'sudo make install' could create root-owned files in the
> >> >> build dir, and that's what this bug report is about.
> >> >>
> >> >> I don't know whether it is important enough to change something. But we
> >> >> should know (and document), that it could happen.
> >> >
> >> > If it's important enough, maybe.
> >> >
> >> > I think "make install" uses chmod to give everyone access to the file
> >> > because some files could be owned by root. If that works, why is the
> >> > ownership important?
> >>
> >> Does everyone get write rights, though? If not, how can you run
> >> commands like "git clean -fxd" as a regular root after "make install"?
> >
> > Sorry, I don't follow: "make install" writes to the installation
> > directory, and invokes chmod on the files installed there, whereas
> > "git clean -fxd" is run on the Git repository, which is a different
> > directory entirely. What am I missing?
>
> AFAIU, the issue here is that "sudo make install" can create root-owned
> files in the build directory.
That can only happen if one runs "sudo make install" before running
"make", i.e. if "make install" finds that some files in the build
directory are outdated.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74400
; Package
emacs
.
(Sat, 04 Jan 2025 17:45:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 74400 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Michael Albinus <michael.albinus <at> gmx.de> writes:
Hi,
> Anyway, I kep it on my todo. Perhaps I find something useful to write
> next days.
What about the appended patch?
Best regards, Michael.
[Message part 2 (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74400
; Package
emacs
.
(Sat, 04 Jan 2025 22:11:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 74400 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> What about the appended patch?
This surely can't harm,yes. I dunno if this is what happened in my case
(my habit is "make + sudo make install"), but I don't know where to dig
or what could have happened either. Ok.
So let me have a look at your patch:
>
> diff --git a/INSTALL b/INSTALL
> index d2705d3a44d..a8c3cd5a8e6 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -671,6 +671,13 @@ for its Lisp files by giving values for 'make' variables as part of
> the command. See the section below called 'MAKE VARIABLES' for more
> information on this.
>
> +If the directories, 'make install' copies the files to, are not writable
> +with your own permissions, you might prefer calling 'sudo make install'.
> +Note, that this command checks the completeness of all needed files; if
Something's weird about your commas (or your comma key). I would remove
all but the third (after the word "permissions") - Eli may be able to
help more.
> +there are missing files they will be generated by internal invocations
> +of 'make'. In order to avoid files with root ownership in your
> +installation directories, you should always call 'make; sudo make install'.
Do you really mean "installation directories"?
Thx,
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74400
; Package
emacs
.
(Sun, 05 Jan 2025 06:56:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 74400 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: Stefan Kangas <stefankangas <at> gmail.com>, 74400 <at> debbugs.gnu.org, Eli
> Zaretskii <eliz <at> gnu.org>
> Date: Sat, 04 Jan 2025 23:11:05 +0100
>
> Michael Albinus <michael.albinus <at> gmx.de> writes:
>
> > +If the directories, 'make install' copies the files to, are not writable
> > +with your own permissions, you might prefer calling 'sudo make install'.
> > +Note, that this command checks the completeness of all needed files; if
>
> Something's weird about your commas (or your comma key). I would remove
> all but the third (after the word "permissions") - Eli may be able to
> help more.
Is the below better?
If the directories where 'make install' installs files are not
writable by your user, you might prefer invoking 'sudo make install'
instead. Note that this latter command checks whether all the files
that are needed for the installation are ready and up-to-date; if
there are missing or outdated files, they will be regenerated or
rebuilt, and might then be created as owned by root. To avoid
creating files with root ownership, you should always invoke
'make && sudo make install' instead.
And I have a question: why not suggest to use 'make && sudo make
install' to begin with, instead of showing a dangerous command and
then explaining why not use it? Like this:
If the directories where 'make install' installs files are not
writable by your user, you might prefer invoking 'make && sudo make
install' instead. This first invokes 'make' to make sure all the
required files are rebuilt with your user's permissions and
ownership, and then installs them using the permissions of root.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74400
; Package
emacs
.
(Sun, 05 Jan 2025 08:22:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 74400 <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
Hi Michael.
>> +If the directories, 'make install' copies the files to, are not writable
>> +with your own permissions, you might prefer calling 'sudo make install'.
>> +Note, that this command checks the completeness of all needed files; if
>
> Something's weird about your commas (or your comma key). I would remove
> all but the third (after the word "permissions") - Eli may be able to
> help more.
Something's weird with my English in general. This is known :-(
>> +there are missing files they will be generated by internal invocations
>> +of 'make'. In order to avoid files with root ownership in your
>> +installation directories, you should always call 'make; sudo make install'.
>
> Do you really mean "installation directories"?
Of course not.
> Thx,
>
> Michael.
Best regards, Michael.
Reply sent
to
Michael Albinus <michael.albinus <at> gmx.de>
:
You have taken responsibility.
(Sun, 05 Jan 2025 08:30:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Michael Heerdegen <michael_heerdegen <at> web.de>
:
bug acknowledged by developer.
(Sun, 05 Jan 2025 08:30:02 GMT)
Full text and
rfc822 format available.
Message #100 received at 74400-done <at> debbugs.gnu.org (full text, mbox):
Version: 30.1
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
> And I have a question: why not suggest to use 'make && sudo make
> install' to begin with, instead of showing a dangerous command and
> then explaining why not use it? Like this:
>
> If the directories where 'make install' installs files are not
> writable by your user, you might prefer invoking 'make && sudo make
> install' instead. This first invokes 'make' to make sure all the
> required files are rebuilt with your user's permissions and
> ownership, and then installs them using the permissions of root.
Thanks a lot, I've installed this version. Pushed to emacs-30, and closing
the bug.
Best regards, Michael.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 02 Feb 2025 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 194 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.