[gentoo-user] Re: Root can't write to files owned by others?

2022-03-10 Thread Nikos Chantziaras

On 10/03/2022 20:44, Michael wrote:

~ # sysctl -a | grep fs.protected_regular
fs.protected_regular = 1


To check the current value of a setting, you can just run:

  sysctl fs.protected_regular

No grep or root needed.




Re: [gentoo-user] Re: Root can't write to files owned by others?

2022-03-10 Thread Peter Böhm
Here is the kernel patch: https://git.kernel.org/pub/scm/linux/kernel/git/
torvalds/linux.git/commit/?id=30aba6656f61ed44cba445a3c0d38b296fa9e8f5

for this:

Am Donnerstag, 10. März 2022, 19:44:46 CET schrieb Michael:
> 
> Just checked and it is so, on openrc:
> 
> ~ # uname -r
> 5.15.26-gentoo
> ~ # sysctl -a | grep fs.protected_regular
> fs.protected_regular = 1







Re: [gentoo-user] Re: Root can't write to files owned by others?

2022-03-10 Thread Michael
On Thursday, 10 March 2022 17:59:00 GMT Laurence Perkins wrote:
> >-Original Message-
> >From: Dr Rainer Woitok 
> >Sent: Thursday, March 10, 2022 9:51 AM
> >To: gentoo-user@lists.gentoo.org; Nikos Chantziaras 
> >Subject: [gentoo-user] Re: Root can't write to files owned by others?
> >
> >Nikos,
> >
> >On Thursday, 2022-03-10 12:21:36 +0200, you wrote:
> >> ...
> >> Are you sure that:
> >> 
> >> sysctl fs.protected_regular=0
> >> 
> >> does not help? I can reproduce it here on my system with kernel
> >> 5.15.27, and setting that sysctl to 0 fixes it immediately.
> >
> >No,  I'm not at all sure.   Since you mentioned  in your first mail that
> >this is normal  when using  "systemd",  I did not pursue  this route any
> >further, because I'm using "openrc".
> >
> >I'll search the web for "fs.protected_regular"  to get a feeling for the
> >consequences and then perhaps set this when I'll again boot kernel vers-
> >ion 5.15.26.
> >
> >Thanks for being persistent :-)
> >
> >Sincerely,
> >
> >  Rainer
> 
> Basically the idea is to keep other users from being able to trick root into
> writing sensitive data to something they control. It's a "systemd thing"
> because, apparently, the systemd developers decided to have systemd enable
> it instead of leaving it in the bailiwick of the distros' configurations.
> But if the default setting changed in a later kernel as well, that would
> potentially affect everyone, so a quick check of what it's set to wouldn't
> be amiss.
> 
> LMP

Just checked and it is so, on openrc:

~ # uname -r
5.15.26-gentoo
~ # sysctl -a | grep fs.protected_regular
fs.protected_regular = 1


signature.asc
Description: This is a digitally signed message part.


RE: [gentoo-user] Re: Root can't write to files owned by others?

2022-03-10 Thread Laurence Perkins
>
>
>-Original Message-
>From: Dr Rainer Woitok  
>Sent: Thursday, March 10, 2022 9:51 AM
>To: gentoo-user@lists.gentoo.org; Nikos Chantziaras 
>Subject: [gentoo-user] Re: Root can't write to files owned by others?
>
>Nikos,
>
>On Thursday, 2022-03-10 12:21:36 +0200, you wrote:
>
>> ...
>> Are you sure that:
>> 
>> sysctl fs.protected_regular=0
>> 
>> does not help? I can reproduce it here on my system with kernel 
>> 5.15.27, and setting that sysctl to 0 fixes it immediately.
>
>No,  I'm not at all sure.   Since you mentioned  in your first mail that
>this is normal  when using  "systemd",  I did not pursue  this route any 
>further, because I'm using "openrc".
>
>I'll search the web for "fs.protected_regular"  to get a feeling for the 
>consequences and then perhaps set this when I'll again boot kernel vers- ion 
>5.15.26.
>
>Thanks for being persistent :-)
>
>Sincerely,
>  Rainer
>
>

Basically the idea is to keep other users from being able to trick root into 
writing sensitive data to something they control.
It's a "systemd thing" because, apparently, the systemd developers decided to 
have systemd enable it instead of leaving it in the bailiwick of the distros' 
configurations.
But if the default setting changed in a later kernel as well, that would 
potentially affect everyone, so a quick check of what it's set to wouldn't be 
amiss.

LMP



[gentoo-user] Re: Root can't write to files owned by others?

2022-03-10 Thread Dr Rainer Woitok
Nikos,

On Thursday, 2022-03-10 12:21:36 +0200, you wrote:

> ...
> Are you sure that:
> 
> sysctl fs.protected_regular=0
> 
> does not help? I can reproduce it here on my system with kernel 5.15.27, 
> and setting that sysctl to 0 fixes it immediately.

No,  I'm not at all sure.   Since you mentioned  in your first mail that
this is normal  when using  "systemd",  I did not pursue  this route any
further, because I'm using "openrc".

I'll search the web for "fs.protected_regular"  to get a feeling for the
consequences and then perhaps set this when I'll again boot kernel vers-
ion 5.15.26.

Thanks for being persistent :-)

Sincerely,
  Rainer



Re: [gentoo-user] Re: Root can't write to files owned by others?

2022-03-10 Thread Grant Taylor

On 3/9/22 11:50 PM, Nikos Chantziaras wrote:

This is normal, at least when using systemd.


How is this a /systemd/ thing?

Is it because systemd is enabling a /kernel/ thing that probably is 
otherwise un(der)used?


I ask as someone who disliked systemd as many others do.  But I fail to 
see how this is systemd's fault.



To disable this behavior, you have to set:

   sysctl fs.protected_regular=0

But you should know what this means when it comes to security. See:

https://www.spinics.net/lists/fedora-devel/msg252452.html


I read that message, but no messages linked therefrom, and don't see any 
security gotchas about disabling (setting to 0) fs.protected_*


I see some value in a tunable to protect against writing to files of 
different type in the guise of protecting against writing somewhere that 
you probably want to not write.  Sort of like shell redirection ">" 
protection for clobbering existing files where you likely meant to 
append ">>" to them.


But I am ignorant as to how this is a /systemd/ thing.



--
Grant. . . .
unix || die



RE: [gentoo-user] Re: Root can't write to files owned by others?

2022-03-10 Thread Laurence Perkins
>On 09/03/2022 20:28, Dr Rainer Woitok wrote:
>> until recently my system behaves sort of strangely:
>> 
>> $ echo x | sudo tee /tmp/file
>> Password:
>> tee: /tmp/file: Permission denied
>> [...]
>> 
>> Since when can't root write to files  it doesn't own?   And not even, if
>> the file has write permission for everybody?
>
>This is normal, at least when using systemd. To disable this behavior, you 
>have to set:
>
>   sysctl fs.protected_regular=0
>
>But you should know what this means when it comes to security. See:
>
>   https://www.spinics.net/lists/fedora-devel/msg252452.html
>
>

And they chose to have systemd set that instead of putting it in sysctl.conf or 
the default kernel settings where it belongs?  Good grief!  

I guess if you're going to use systemd you need to subscribe to the Fedora 
mailing lists so you get at least a little notice before they break things.

LMP


[gentoo-user] Re: permission denied while fetching distfile using ebuild

2022-03-10 Thread Anatoly Oreshkin
I've corrected the file /etc/make.conf as follows:
FETCHCOMMAND="/usr/bin/wget --no-check-certificate -P  \${DISTDIR}
 \${URI}"
RESUMECOMMAND="/usr/bin/wget -c --no-check-certificate -P  \${DISTDIR}
\${URI}"

After that I've run command:
ebuild ./pum-outss-1.0.0.ebuild manifest clean unpack

This time file pum-outss-1.0.0.tar.gz is downloaded and saved
pum-outss-1.0.0.tar.gz[ <=>
]  26.47K  --.-KB/s
   in 0.05s

2022-03-10 14:00:00 (559 KB/s) -
‘/var/cache/distfiles/pum-outss-1.0.0.tar.gz’ saved [27103]
But  I've got the following errors:

pum-outss-1.0.0.tar.gz[ <=>
]  26.47K  --.-KB/s
   in 0.05s

2022-03-10 14:00:00 (559 KB/s) -
‘/var/cache/distfiles/pum-outss-1.0.0.tar.gz’ saved [27103]

!!! Stating source file failed... movefile()
!!! [Errno 2] No such file or directory:
b'/var/cache/distfiles/pum-outss-1.0.0.tar.gz.__download__'
Traceback (most recent call last):
  File "/usr/lib/python-exec/python3.9/ebuild", line 349, in 
a = portage.doebuild(ebuild, arg, settings=tmpsettings,
  File
"/usr/lib/python3.9/site-packages/portage/package/ebuild/doebuild.py", line
1376, in doebuild
return not digestgen(mysettings=mysettings, myportdb=mydbapi)
  File
"/usr/lib/python3.9/site-packages/portage/package/ebuild/digestgen.py",
line 161, in digestgen
if not fetch({myfile: uris}, mysettings):
  File "/usr/lib/python3.9/site-packages/portage/package/ebuild/fetch.py",
line 1959, in fetch
_movefile(
  File "/usr/lib/python3.9/site-packages/portage/__init__.py", line 599, in
_movefile
raise portage.exception.PortageException("mv '%s' '%s'" % (src, dest))
portage.exception.PortageException: mv
'/var/cache/distfiles/pum-outss-1.0.0.tar.gz.__download__'
'/var/cache/distfiles/pum-outss-1.0.0.tar.gz'

What is wrong ?  Any ideas ?










чт, 10 мар. 2022 г. в 16:07, Anatoly Oreshkin :

>
> Hello,
>
> I am trying to create my first  package using ebuild.
> I've created ebuild file pum-outss-1.0.0.ebuild in directory
> /var/db/repos/pum-outss/dev-python/pum-outss
>
> The file pum-outss-1.0.0.ebuild  has following content:
> EAPI=7
> DESCRIPTION="Exchange data between PUM and OUTSS"
> HOMEPAGE="https://domain.org/strela-project/pum-outss;
> SRC_URI="
> https://domain.org/strela-project/pum-outss/pum-outss-1.0.0.tar.gz;
> #S="${WORKDIR}/${P}"
> LICENSE="GPLv3.0"
> SLOT="0"
> KEYWORDS="~amd64"
> RDEPEND="dev-python/confluent-kafka"
> #DEPEND="${RDEPEND}"
> #BDEPEND="virtual/pkgconfig"
> #src_unpack() {
> #unpack ${P}.tar.gz
> #}
>
> The rest of the file are comments.
>
> I've created  my repository pum-outss by the command
> eselect repository create pum-outss
> ...
> Adding pum-outss to /etc/portage/repos.conf/eselect-repo.conf ...
> Repository pum-outss created and added
>
> The file /etc/portage/repos.conf/eselect-repo.conf content:
> [guru]
> location = /var/db/repos/guru
> sync-type = git
> sync-uri = https://github.com/gentoo-mirror/guru.git
>
> [pum-outss]
> location = /var/db/repos/pum-outss
>
> To fetch pum-outss-1.0.0.tar.gz using wget  with parameter
> --no-check-certificate
> I've created the file /etc/make.conf with such lines:
>
> FETCHCOMMAND="/usr/bin/wget --no-check-certificate  \${URI} "
> RESUMECOMMAND="/usr/bin/wget -c --no-check-certificate  \${URI} "
>
> Then I've run the following commands:
>
> cd /var/db/repos/pum-outss/dev-python/pum-outss
> ebuild ./pum-outss-1.0.0.ebuild manifest clean unpack
>
> !!! Found 2 make.conf files, using both '/etc/make.conf' and
> '/etc/portage/make.conf'
> !!! FEATURES=fakeroot is enabled, but the fakeroot binary is not installed.
> !!! FETCHCOMMAND does not contain the required ${FILE} parameter.
> !!! RESUMECOMMAND does not contain the required ${FILE} parameter.
> !!! Refer to the make.conf(5) man page for information about how to
> !!! correctly specify FETCHCOMMAND and RESUMECOMMAND.
> >>> Downloading '
> http://distfiles.gentoo.org/distfiles/8e/pum-outss-1.0.0.tar.gz'
> --2022-03-10 12:45:01--
> http://distfiles.gentoo.org/distfiles/8e/pum-outss-1.0.0.tar.gz
> Resolving distfiles.gentoo.org... 195.181.175.49, 195.181.175.45,
> 195.181.174.7, ...
> Connecting to distfiles.gentoo.org|195.181.175.49|:80... connected.
> HTTP request sent, awaiting response... 404 Not Found
> 2022-03-10 12:45:03 ERROR 404: Not Found.
>
> No digest file available and download failed.
>
> !!! FETCHCOMMAND does not contain the required ${FILE} parameter.
> !!! RESUMECOMMAND does not contain the required ${FILE} parameter.
> !!! Refer to the make.conf(5) man page for information about how to
> !!! correctly specify FETCHCOMMAND and RESUMECOMMAND.
> >>> Downloading '
> https://domain.org/strela-project/pum-outss/pum-outss-1.0.0.tar.gz'
> --2022-03-10 12:45:03--
> https://domain.org/strela-project/pum-outss/pum-outss-1.0.0.tar.gz
> Resolving domain.org... x.x.x.x
> Connecting to domain.org|x.x.x.x|:443... 

[gentoo-user] permission denied while fetching distfile using ebuild

2022-03-10 Thread Anatoly Oreshkin
Hello,

I am trying to create my first  package using ebuild.
I've created ebuild file pum-outss-1.0.0.ebuild in directory
/var/db/repos/pum-outss/dev-python/pum-outss

The file pum-outss-1.0.0.ebuild  has following content:
EAPI=7
DESCRIPTION="Exchange data between PUM and OUTSS"
HOMEPAGE="https://domain.org/strela-project/pum-outss;
SRC_URI="https://domain.org/strela-project/pum-outss/pum-outss-1.0.0.tar.gz;
#S="${WORKDIR}/${P}"
LICENSE="GPLv3.0"
SLOT="0"
KEYWORDS="~amd64"
RDEPEND="dev-python/confluent-kafka"
#DEPEND="${RDEPEND}"
#BDEPEND="virtual/pkgconfig"
#src_unpack() {
#unpack ${P}.tar.gz
#}

The rest of the file are comments.

I've created  my repository pum-outss by the command
eselect repository create pum-outss
...
Adding pum-outss to /etc/portage/repos.conf/eselect-repo.conf ...
Repository pum-outss created and added

The file /etc/portage/repos.conf/eselect-repo.conf content:
[guru]
location = /var/db/repos/guru
sync-type = git
sync-uri = https://github.com/gentoo-mirror/guru.git

[pum-outss]
location = /var/db/repos/pum-outss

To fetch pum-outss-1.0.0.tar.gz using wget  with parameter
--no-check-certificate
I've created the file /etc/make.conf with such lines:

FETCHCOMMAND="/usr/bin/wget --no-check-certificate  \${URI} "
RESUMECOMMAND="/usr/bin/wget -c --no-check-certificate  \${URI} "

Then I've run the following commands:

cd /var/db/repos/pum-outss/dev-python/pum-outss
ebuild ./pum-outss-1.0.0.ebuild manifest clean unpack

!!! Found 2 make.conf files, using both '/etc/make.conf' and
'/etc/portage/make.conf'
!!! FEATURES=fakeroot is enabled, but the fakeroot binary is not installed.
!!! FETCHCOMMAND does not contain the required ${FILE} parameter.
!!! RESUMECOMMAND does not contain the required ${FILE} parameter.
!!! Refer to the make.conf(5) man page for information about how to
!!! correctly specify FETCHCOMMAND and RESUMECOMMAND.
>>> Downloading '
http://distfiles.gentoo.org/distfiles/8e/pum-outss-1.0.0.tar.gz'
--2022-03-10 12:45:01--
http://distfiles.gentoo.org/distfiles/8e/pum-outss-1.0.0.tar.gz
Resolving distfiles.gentoo.org... 195.181.175.49, 195.181.175.45,
195.181.174.7, ...
Connecting to distfiles.gentoo.org|195.181.175.49|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2022-03-10 12:45:03 ERROR 404: Not Found.

No digest file available and download failed.

!!! FETCHCOMMAND does not contain the required ${FILE} parameter.
!!! RESUMECOMMAND does not contain the required ${FILE} parameter.
!!! Refer to the make.conf(5) man page for information about how to
!!! correctly specify FETCHCOMMAND and RESUMECOMMAND.
>>> Downloading '
https://domain.org/strela-project/pum-outss/pum-outss-1.0.0.tar.gz'
--2022-03-10 12:45:03--
https://domain.org/strela-project/pum-outss/pum-outss-1.0.0.tar.gz
Resolving domain.org... x.x.x.x
Connecting to domain.org|x.x.x.x|:443... connected.
WARNING: cannot verify domain.org's certificate, issued by ‘CN=GeoTrust RSA
CA 2018,OU=www.digicert.com,O=DigiCert Inc,C=US’:
  Unable to locally verify the issuer's authority.
HTTP request sent, awaiting response... 302 Found
Location: https://domain.org/users/sign_in [following]
--2022-03-10 12:45:04--  https://domain.org/users/sign_in
Reusing existing connection to domain.org:443.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
pum-outss-1.0.0.tar.gz: Permission denied

Cannot write to ‘pum-outss-1.0.0.tar.gz’ (Success)
No digest file available and download failed.

!!! Couldn't download 'pum-outss-1.0.0.tar.gz'. Aborting.
!!! Fetch failed for pum-outss-1.0.0.tar.gz, can't update Manifest

However using wget by hand  I can download the file pum-outss-1.0.0.tar.gz

/usr/bin/wget --no-check-certificate
https://domain.org/strela-project/pum-outss/pum-outss-1.0.0.tar.gz
--2022-03-10 12:55:30--
https://domain.org/strela-project/pum-outss/pum-outss-1.0.0.tar.gz
Resolving domain.org... x.x.x.x
Connecting to domain.org x.x.x.x|:443... connected.
WARNING: cannot verify domain.org's certificate, issued by ‘CN=GeoTrust RSA
CA 2018,OU=www.digicert.com,O=DigiCert Inc,C=US’:
  Unable to locally verify the issuer's authority.
HTTP request sent, awaiting response... 302 Found
Location: https://domain.org/users/sign_in [following]
--2022-03-10 12:55:30--  https://domain.org/users/sign_in
Reusing existing connection to domain.org:443.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘pum-outss-1.0.0.tar.gz’

pum-outss-1.0.0.tar.gz[ <=>
]  26.47K  --.-KB/s
   in 0s

2022-03-10 12:55:30 (51.8 MB/s) - ‘pum-outss-1.0.0.tar.gz’ saved [27103]


Why is pum-outss-1.0.0.tar.gz: Permission denied  ?
What may be the cause ?   Any ideas ?


Re: [gentoo-user] Re: Root can't write to files owned by others?

2022-03-10 Thread Björn Fischer

Hello Rainer,


Big thanks to all kind people making suggestions.  But up to now nothing
helped.


on my rig I can fully reproduce Nikos' statement.

Additionally, on 5.15.16 "fs.protected_regular" defaults to "0" while on 
5.15.27 it defaults to "1".


Cheers,

Björn



[gentoo-user] Re: Root can't write to files owned by others?

2022-03-10 Thread Nikos Chantziaras

On 10/03/2022 11:55, Dr Rainer Woitok wrote:

Big thanks to all kind people making suggestions.  But up to now nothing
helped.


Are you sure that:

sysctl fs.protected_regular=0

does not help? I can reproduce it here on my system with kernel 5.15.27, 
and setting that sysctl to 0 fixes it immediately.





[gentoo-user] Re: Root can't write to files owned by others?

2022-03-10 Thread Dr Rainer Woitok
Greetings,

On Wednesday, 2022-03-09 19:28:49 +0100, I myself wrote:

> ...
>$ touch /tmp/file
>$ ls -l /tmp/file
>-rw--- 1 rainer rainer 0 2022-03-09 19:06 /tmp/file
>$ echo x | sudo tee /tmp/file
>Password: 
>tee: /tmp/file: Permission denied
>x
>$ ...
>$

Big thanks to all kind people making suggestions.  But up to now nothing
helped.

> ...
> When I'll have time to reboot,  I'll test the  above commands  on my old
> kernel, 5.15.19.

Surprisingly,  this did in fact help.   My rig is back  to normal behav-
iour! :-O

For what it's worth,  these were  the only kernel  configuration changes
when building kernel 5.15.26 while running kernel 5.15.19 using

   # make olddefconfig

   -CONFIG_CC_VERSION_TEXT="gcc (Gentoo 11.2.0 p1) 11.2.0"
   +CONFIG_CC_VERSION_TEXT="gcc (Gentoo 11.2.1_p20220115 p4) 11.2.1 20220115"
   -CONFIG_GCC_VERSION=110200
   +CONFIG_GCC_VERSION=110201
   +# CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION is not set

So again: what am I missing?  For the time being I'll stay with this old
kernel version, even though it's no longer available upstream.

Sincerely,
  Rainer