On Thu, Jan 26, 2023 at 10:26:34AM +0700, Max Nikulin wrote:
> Greg, I agree with your warnings. Just out of curiosity, is there a reason
> why the following variant may still be unsafe?
>
> runas() { local who=$1; shift; su --login "$who" --shell=/bin/bash
> --command='"$0" "$@"' -- "$@"; }
1) h
On 25/01/2023 21:52, Greg Wooledge wrote:
On Wed, Jan 25, 2023 at 03:36:33PM +0100, Yassine Chaouche wrote:
runas_wwwdata ()
{
echo su - www-data -s /bin/bash -c "$*";
su - www-data -s /bin/bash -c "$*"
}
...
su(1) is pretty much the WORST possible choice for this, as it forces
you t
Hi,
piorunz wrote:
> read attempts continue,
Obviously your drive groper is different from Richmond's. Both get lured
into their activities by the kernel bugs.
> Inserting blank disc on every reboot is not a solution in my opinion. And I
> didn't verified it myself,
It would be interesting to
On Tue 24 Jan 2023 at 18:29:38 (+0100), Vincent Lefevre wrote:
> On 2023-01-24 10:36:05 -0600, David Wright wrote:
> > On Tue 24 Jan 2023 at 15:34:49 (+0100), Vincent Lefevre wrote:
> [...]
> > > For instance, if I paste the following 3 lines
> > >
> > > foo1
> > > foo2
> > > foo3
> > >
> > > in
On 25/01/2023 15:26, Thomas Schmitt wrote:
it might be that there are no further (periodic) read attempts.
If the messages only appear once during the boot procedure, then i think
the issue is explored as far as possible without starting kernel
programming.
Just to briefly comment on this - re
Reported both as a Debian kernel issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029584
(since I thought for a while that it was that)
And as a libinput issue:
https://gitlab.freedesktop.org/libinput/libinput/-/issues/852
I dunno what the proper fix would be, or where, but I am sure
On Wed, Jan 25, 2023 at 2:54 AM jeremy ardley wrote:
>
> [...]
> Rechecked, thanks. The vendor directory didn't have x permissions.
> Fixed. Now to track down all the other files similarly afflicted in the
> screaming pile of manure called drupal.
>
> root@gram01:/# ls -ld var/www/grammartiste.com
On Wed, Jan 25, 2023 at 2:34 AM wrote:
>
> On Wed, Jan 25, 2023 at 02:51:05PM +0800, jeremy ardley wrote:
>
> [...]
>
> > 0.41 lstat("/var/www/grammartiste.com/web/vendor/autoload.php",
> > 0x7fffdc580970) = -1 EACCES (Permission denied)
> > 0.34 lstat("/var/www/grammartiste.com
Hi,
Richmond wrote:
> VENDOR MODEL SIZE PHY-SEC LOG-SEC
> HL-DT-ST HL-DT-ST_DVDRAM_GH15F 204820482048
> It has stayed like this after I removed it.
Next question would be whether the error messages stopped after this.
But re-reading your initial post:
> > I see erro
Richmond writes:
> "Thomas Schmitt" writes:
>
>> Hi,
>>
>> i wrote:
>>> > If you have some blank optical medium, then try whether the emitter of
>>> > the read attempt can be discouraged if the drive is perceived as offering
>>> > just one block of 2048 bytes.
>>
>> Richmond wrote:
>>> I don't k
Greg Wooledge (12023-01-25):
> When investigating permissions, there's really no reason to do the
> investigation as a non-root user.
When investigating permissions, doing your tests as root instead of the
user who is having the permissions issues, is a sure way for hiding the
issue.
Nothing to a
On Wed, Jan 25, 2023 at 03:36:33PM +0100, Yassine Chaouche wrote:
> Le 1/25/23 à 3:22 PM, Nicolas George a écrit :
> > For the current problem:
> >
> > sudo -u www-data namei /var/www/nextcloud/3rdparty/autoload.php
> >
> > … will cause the command to be executed in an environment closer to the
>
"Thomas Schmitt" writes:
> Hi,
>
> i wrote:
>> > If you have some blank optical medium, then try whether the emitter of
>> > the read attempt can be discouraged if the drive is perceived as offering
>> > just one block of 2048 bytes.
>
> Richmond wrote:
>> I don't know how to do that. Do you mean
On Sun, Jan 22, 2023 at 09:33:42PM +0100, Thomas Schmitt wrote:
> Hi,
>
> Mike wrote:
> > I don't think that it's a bad grub binary, as I have reinstalled several
> > times, with the same result.
>
> But if it's indeed shim which is complaining then it complains about the
> content of grubx64.efi
Le 1/25/23 à 3:22 PM, Nicolas George a écrit :
For the current problem:
sudo -u www-data namei /var/www/nextcloud/3rdparty/autoload.php
… will cause the command to be executed in an environment closer to the
one that causes the problem, and therefore is more likely to reveal it.
Use any command
Yassine Chaouche (12023-01-25):
> I prefer to use namei -l.
namei is good indeed.
> root@cloud[10.10.10.84/24] 15:15:43 ~ # namei -l
> /var/www/nextcloud/3rdparty/autoload.php
For the current problem:
sudo -u www-data namei /var/www/nextcloud/3rdparty/autoload.php
… will cause the command to
Le 1/25/23 à 2:07 PM, Greg Wooledge a écrit :
On Wed, Jan 25, 2023 at 07:34:54AM -0500, Dan Ritter wrote:
jeremy ardley wrote:
I have vague memories there are more file flags in newer Linux file systems?
There are extended attributes, of which the only one you are
likely to encounter is i,
Le 1/25/23 à 8:44 AM, jeremy ardley a écrit :
Anyway tree permissions:
root@gram01:/# ls -ld var
drwxr-xr-x 12 root root 4096 Nov 7 23:30 var
root@gram01:/# ls -ld var/www
drwxr-xr-x 5 www-data www-data 4096 Jan 23 16:33 var/www
root@gram01:/# ls -ld var/www/grammartiste.com/
drwxr-xr-
Hi,
jeremy ardley wrote:
> > > I have vague memories there are more file flags in newer Linux file
> > > systems?
Dan Ritter wrote:
> > There are extended attributes, [...]
> > lsattr and chattr are the relevant commands.
Nicolas George wrote:
> What you describe are file attributes specific to
Hi,
i wrote:
> > If you have some blank optical medium, then try whether the emitter of
> > the read attempt can be discouraged if the drive is perceived as offering
> > just one block of 2048 bytes.
Richmond wrote:
> I don't know how to do that. Do you mean make a DVD with 1 block of data?
Just
On Wed, Jan 25, 2023 at 07:34:54AM -0500, Dan Ritter wrote:
> jeremy ardley wrote:
> > I have vague memories there are more file flags in newer Linux file systems?
>
> There are extended attributes, of which the only one you are
> likely to encounter is i, immutable. It is occasionally useful
> t
Dan Ritter (12023-01-25):
> There are extended attributes, of which the only one you are
> likely to encounter is i, immutable. It is occasionally useful
> to nail down the state of a file even when something properly
> has write permissions for it.
>
> lsattr and chattr are the relevant commands.
Bushra Perveen wrote:
> Hi Team,
>
> Please provide the EOL and EOS dates for the below mentioned software's.
>
>
> whiptail 0.5 (Linux)
>
> P11 Glue Utilities 0.2 (Linux)
>
> virt-what 1 (Linux)
>
> HTTP Client 6 (Linux)
>
> virt-what 6 (Linux)
>
> DStat 0.7 (Linux)
If you would like t
jeremy ardley wrote:
> I have vague memories there are more file flags in newer Linux file systems?
There are extended attributes, of which the only one you are
likely to encounter is i, immutable. It is occasionally useful
to nail down the state of a file even when something properly
has write p
"Thomas Schmitt" writes:
> I assume that you will see the same result there.
lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr*
VENDOR MODEL SIZE PHY-SEC LOG-SEC
HL-DT-ST HL-DT-ST_DVDRAM_GH15F 1073741312 512 512
5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-
On 25/01/2023 10:38, Thomas Schmitt wrote:
Are users of Debian 10 (actually of kernel 4.19) here who are willing to
run
lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr*
directly after booting with empty drive tray ?
$ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr*
VENDOR MODE
Hi,
i wrote:
> > Back in 2020 i would quite surely have noticed
> > if that behavior had been shown.
Richmond wrote:
> lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr*
> VENDOR MODELSIZE PHY-SEC LOG-SEC
> TSSTcorp TSSTcorp_DVD+_-RW_TS-L632H 1073741312 512
Hi Team,
Please provide the EOL and EOS dates for the below mentioned software's.
whiptail 0.5 (Linux)
P11 Glue Utilities 0.2 (Linux)
virt-what 1 (Linux)
HTTP Client 6 (Linux)
virt-what 6 (Linux)
DStat 0.7 (Linux)
Thanks,
Bushra
From: Bushra Perveen
Sent:
"Thomas Schmitt" writes:
>
> Are users of Debian 10 (actually of kernel 4.19) here who are willing to
> run
> lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr*
> directly after booting with empty drive tray ?
lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr*
VENDOR MODEL
Hi,
piorunz wrote:
> CD inserted:
> $ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr0
> VENDOR MODEL SIZE PHY-SEC LOG-SEC
> hp hp_DVDRW_GUE1N 62765670420482048
> DVD inserted:
> $ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr0
> VENDOR MODEL
On 24/01/2023 18:58, Thomas Schmitt wrote:
Hi,
the log messages about "unaligned transfer" would be explained if indeed
the block size of the drive would be mistaken as 512 bytes rather than
2048 bytes.
So it might be interesting to let lsblk report "sector" sizes as perceived
by the kernel:
Hello,
I'm trying to find some help in order to debug or resolve the issues I'm
facing. Hopefully, someone will be able to help me here.
The main problem that prevents me from trying to solve it myself is the
absence of logs and messages.
So, my laptop MSI Stealth GS77 with a Debian testin
On Wed, 25 Jan 2023 at 14:54, Matthew McAllister
wrote:
> BTW, this is what the logs contained when the device was last successfully
> started. (It is indeed the bluetooth chip; no idea why it's not a PCI device.)
>
> 2023-01-04T23:44:08.519572-08:00 cockpit kernel: [3.927596] usb 1-5: new
On Wed, Jan 25, 2023 at 03:53:50PM +0800, jeremy ardley wrote:
[...]
> Rechecked, thanks. The vendor directory didn't have x permissions. Fixed.
> Now to track down all the other files similarly afflicted in the screaming
> pile of manure called drupal.
uh-oh ;-)
Cheers & good luck
--
t
sign
On Wed, 2023-01-25 at 08:06 +, Tixy wrote:
> My final idea: have you used a wireless keyboard or mouse?
or wireless headphones.
On Tue, 2023-01-24 at 19:36 -0800, Matthew McAllister wrote:
[...]
> BTW, this is what the logs contained when the device was last
> successfully started. (It is indeed the bluetooth chip; no idea why
> it's not a PCI device.)
My final idea: have you used a wireless keyboard or mouse? (I'm
clutchi
36 matches
Mail list logo
