On 10/24/24 20:01, David Wright wrote:

Because of the ownership:

$ ls -l /var/cache/apt/archives/
total 4
-rw-r----- 1 root root 0 Apr 16 2022 lock
drwx------ 2 _apt root 4096 Oct 22 19:00 partial
$

we can assume that _apt is the user that actually downloads packages
(into partial/) before APT installs them. But your assumption that
tmp_sh can be read by any user (including _apt) is wrong: you need
execute permission on all directories traversed along the path, even
when you “know what you're looking for”.

Fair enough. Should I chmod a+x /root/.synaptic/tmp then, or is there a
nicer way?

Also, I've been running synaptic as "sudo synaptic" and this is the first
time I've got that message. I used to do "synaptic-pkexec" but it would ask
me for my password each time I ran it, whereas with sudo if I ran it from
the same terminal again within a few minutes, my previous authentication was good enough.

--
You can't get a leopard to change his spots... You can explain it care-
fully to the leopard, but it will just sit there lookng at you, knowing
that you are made of meat. After a while it will perhaps kill you.
Geoffrey Pullum, Language Log (2007-01-04)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Because of the ownership:

$ ls -l /var/cache/apt/archives/
total 4
-rw-r----- 1 root root 0 Apr 16 2022 lock
drwx------ 2 _apt root 4096 Oct 22 19:00 partial
$

we can assume that _apt is the user that actually downloads packages
(into partial/) before APT installs them. But your assumption that
tmp_sh can be read by any user (including _apt) is wrong: you need
execute permission on all directories traversed along the path, even
when you “know what you're looking for”. (And if you don't know, then
you need read permission as well.)

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu 24 Oct 2024 at 21:20:28 (-0500), David Wright wrote:

[ … ]

Apologies ditto.

That should have read:

Apologies, BTW, for losing the threading, but for some reason, my
email host rejected so many permutations of my post (nine, in fact)
that it became apparent the problem might lie in the headers rather
than the body. (For example, having Reply-to = To scores really badly.)

Anyway, it appears I can't reply to eben's posts in this thread but,
if this gets through, I can reply to my own. (And to Daniel Roberts
earlier.) What triggers their spam detector software, presumably
"mailclean11", I have no idea.

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu 24 Oct 2024 at 20:34:18 (-0400), [email protected] wrote:

On 10/24/24 20:01, David Wright wrote:

Because of the ownership:

$ ls -l /var/cache/apt/archives/
total 4
-rw-r----- 1 root root 0 Apr 16 2022 lock
drwx------ 2 _apt root 4096 Oct 22 19:00 partial
$

we can assume that _apt is the user that actually downloads packages
(into partial/) before APT installs them. But your assumption that
tmp_sh can be read by any user (including _apt) is wrong: you need
execute permission on all directories traversed along the path, even
when you “know what you're looking for”.

Apologies ditto.

Fair enough. Should I chmod a+x /root/.synaptic/tmp then, or is there a nicer way?

Not using synaptic, I don't know why that path was chosen. But
you'd need world-execute all the way down from /root itself.

When I install yt-dlp, being lazy I download the package from packages.debian.org, choosing the most recent version, typically
trixie's. I store it under /home/debian/trixie (or whatever), and
# apt-get install full-path
I consider this safe, and ignore the warning that's issued. IIRC,
my warning starts with "N: Download is performed … ".

I do this because I'm too lazy to change my sources.list, and
that has the side-effect that I can't accidentally install any
non-stable packages by way of Depends/Recommends/Suggests.

In the past I have placed packages in /var/cache/apt/archives/,
but I'm not sure whether I used apt-get with a full path,
or dpkg -i; it was so long ago.

Also, I've been running synaptic as "sudo synaptic" and this is the first time I've got that message.

Well, I'll admit that I'm mystified as to what the 283682-byte file
called tmp_sh actually is, and how it was obtained.

I used to do "synaptic-pkexec" but it would ask
me for my password each time I ran it, whereas with sudo if I ran it from
the same terminal again within a few minutes, my previous authentication was good enough.

What I've never resolved is under what circumstances does
# apt-get install full-path
copy full-path via /var/cache/apt/archives/partial/ into /var/cache/apt/archives/, leaving the copy in the cache,
and install it from there; or just install it directly
from full-path without all the copying. But I suspect that:
. performing the copying step ⇒ no warning,
. installing directly ⇒ warning issued.

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dunno, if it is correct:

I fell into the same issue. Just deleted the complete folder, then started synaptic again and the folder was new created = issue gone.

Not sure, if this is enough. Maybe the reason is, debian is working on umask settings and (as far as I read), there is normally no "default" setting for umask in debian. It is just led to admininitrators choice.

There is also a difference between directly logging in as root and changing to root with su- .

This will be fixed in trixie.

Hans

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/24/24 22:33, David Wright wrote:

Anyway, it appears I can't reply to eben's posts in this thread but,
if this gets through, I can reply to my own. (And to Daniel Roberts earlier.) What triggers their spam detector software, presumably "mailclean11", I have no idea.

I don't know why I'm special. I'm using Thunderbird and my mail goes out through gmx.us.

--
Hanlon's Razor: "Never attribute to malice that which can be
adequately explained by stupidity." Derived from Robert Heinlein

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Eben, don't worry, got into same issue with some mails sent from debian.

These are then marked with the "*****SPAM*****" tag in the header, althpough
it is no spam. It as someting to do with DKIM. I already noticed debian of it, but they say, they are not responsible and some other mailer is doing wrong things (in my case it shall be megamail). I have to bleive them, but it woinders, why only mails from are affected this way.

But before starting some anger somewhere, I made my own spamrule and set mails from debian to the whitelist in my spamrules = issue solved.

However, it might also still effect other people, but do not know and can not prove it.

Just for info.....

Best regards

Hans

I don't know why I'm special. I'm using Thunderbird and my mail goes out through gmx.us.

--
Hanlon's Razor: "Never attribute to malice that which can be
adequately explained by stupidity." Derived from Robert Heinlein

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri 25 Oct 2024 at 09:19:30 (-0400), eben@somewhere wrote:

Not using synaptic, I don't know why that path was chosen. But
you'd need world-execute all the way down from /root itself.

Well the chmod thing is not acceptable.

Totally reasonable; any world-readable file in /root
would be exposed to being copied out by anybody.

Well, I'll admit that I'm mystified as to what the 283682-byte file
called tmp_sh actually is, and how it was obtained.

eben@cerberus:~$ sudo file /root/.synaptic/tmp/tmp_sh
[sudo] password for eben:
/root/.synaptic/tmp/tmp_sh: PNG image data, 825 x 861, 8-bit/color RGBA, non-interlaced

I asked for a screenshot of some package, and that appears to be it. As to why it's there, couldn't say. I don't need to save it for posterity or anything.

If it's a screenshot, it was presumably taken over two years ago.
I have no idea why it's involved in the current discussion, but
it does show the value of pasting commands and their output into
posts, as so often mentioned here.

When I receive this warning, the surrounding context relates to
the /package/ file mentioned in the warning:

# apt-get install ./yt-dlp_2023.01.06-1_all.deb
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'yt-dlp' instead of './yt-dlp_2023.01.06-1_all.deb'
Suggested packages:
libfribidi-bin | bidiv phantomjs
The following NEW packages will be installed:
yt-dlp
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/1739 kB of archives.
After this operation, 9644 kB of additional disk space will be used.
Get:1 /root/yt-dlp_2023.01.06-1_all.deb yt-dlp all 2023.01.06-1 [1739 kB]
[ … ]
Preparing to unpack .../yt-dlp_2023.01.06-1_all.deb ...
Unpacking yt-dlp (2023.01.06-1) ...
Setting up yt-dlp (2023.01.06-1) ...
[ … ]
N: Download is performed unsandboxed as root as file
'/root/yt-dlp_2023.01.06-1_all.deb' couldn't be accessed
by user '_apt'. - pkgAcquire::Run (13: Permission denied)
#

This shows a consistent view of a package file being installed.
I was writing under the misapprehension that your 283682-byte
file was a temporary copy of a package file with a bizarre name
and a plausible timestamp.

Was Synaptic/APT/dpkg trying to install it?

It's only a warning so not critical to fix, so I guess I have time to try non-destructive means of making it not happen. Thanks.

I'm an "su -" person that doesn't run GUIs as root, so I'm not best
equipped to know how to avoid the synaptic-pkexec issue except by
not quitting, but leaving it running, say, in a taskbar or whatever.
What happens if you sudo synaptic-pkexec?

I ignore the warning because when I'm using apt-get install full-path,
my level of paranoia is assuaged by checking the MD5 listed at the
bottom of the p.d.o/…/download page before I install it.

If I desperately wanted to avoid it, the easiest way would be to place
the package file into /tmp/ with world-readable permission, and
apt-get install it from there¹, but I don't see the point.

As for posting replies to your posts, the ridiculous thing about
the spam detector is that I can only see what it says about messages
that pass, so it's difficult to guess what can raise the score on
a specific post. However, I (and anybody else) do see lines like:
RSPAMD_URIBL(3.00)[---.--:email];
↑↑↑↑↑↑ erased your address
caused by the attribution in /just/ the body. Perhaps having that
address in the In-reply-to and References as well is enough to
tip the balance. This post includes those headers but no mention
in the body, so we'll see.

¹ I just tested that with:
$ namei -l /tmp/yt-dlp_2024.10.22-1_all.deb
f: /tmp/yt-dlp_2024.10.22-1_all.deb
drwxr-xr-x root root /
drwxrwxrwt root root tmp
-rw-r--r-- auser auser yt-dlp_2024.10.22-1_all.deb
$ md5sum /tmp/yt-dlp_2024.10.22-1_all.deb
b1cdd6f0b2e50cc875017fa9547d209c /tmp/yt-dlp_2024.10.22-1_all.deb
$

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)