[gentoo-user] sys-devel/llvm and LLVM_TARGETS
Howdy, I just noticed this in my updates: [ebuild U ] sys-devel/llvm-13.0.1:13::gentoo [13.0.0:13::gentoo] USE="binutils-plugin%* libffi ncurses xml -debug -doc -exegesis -libedit -test -xar -z3 (-gold%*)" ABI_X86="32 (64) (-x32)" LLVM_TARGETS="(AArch64*) (AMDGPU) (ARM*) (AVR*) (BPF) (Hexagon*) (Lanai*) (MSP430*) (Mips*) (NVPTX) (PowerPC*) (RISCV*) (Sparc*) (SystemZ*) (WebAssembly*) (X86) (XCore*) (-ARC) (-CSKY) (-M68k) (-VE)" The LLVM_TARGETS= part looks odd. Why do I need ARM, PowerPC, Sparc etc here? Is that correct? The old still installed version doesn't have those enabled. Thanks. Dale :-) :-)
Re: [gentoo-user] Re: tensorflow-2.5.0-r1 compilation failed
пт, 11 мар. 2022 г. в 20:49, Mark Knecht : > > On Fri, Mar 11, 2022 at 10:48 AM gevisz wrote: > > > > > In addition to the old CPU, I have quite an old video card, > > namely, ATI R4770. However, I still believe that it is possible > > to compile tensorflow so that it could run on my hardware. > > At least, I did it for tensorflow-2.7.0 on 21-11-2021. > > > > Stay safe and return to us when you can. Thank you. > As for me I moved on and bought a new computer so my > hardware issues with tensorflow are behind me for now. Yes, probably, it would be the solution.
Re: [gentoo-user] Re: Root can't write to files owned by others?
On Fri, Mar 11, 2022 at 12:26 PM Rich Freeman wrote: > > On Fri, Mar 11, 2022 at 1:23 PM Mark Knecht wrote: > > > > To me the overriding idea of not letting any user, including root, > > mess around in a pipe makes logical sense, but as the OP has showed I > > guess there were valid uses for this feature pre-patch, and it seems > > that a user can override the feature by setting some bits if they need > > to and really think they know what they are doing. > > There has been a long history of exploits on Unix involving places > like /tmp because it is so easy for different users to step on each > other's toes, possibly deliberately. The sorts of things that can go > wrong are usually not intuitive, though anybody creating files in a > world/group-writable location really should be aware of them. This is > also the reason why you should never have "." in your path. > > Usually attacks work by predicting some file that a root-controlled > process is about to create, and then creating it before the process > does, so that the process ends up opening an existing file that you > control instead of a new file that it controls. Programmers sometimes > anticipate issues and create their own safeguards, but fail to > understand race conditions so there can be a time gap between after > the sanity checks are run and when the file is created. > > There is also a principle in security in general that suggests that > any situation where data can pass between two different privilege > levels needs to be safeguarded by default. I believe there are > operating system models (probably including SELinux) that block such > flows/transitions by default, and force programmers to explicitly > define them so that they can't happen inadvertently. Basically if a > non-privileged process can only interact with a privileged process via > very tightly controlled APIs then it is much easier to secure the > process, even if a programmer can't anticipate all the ways that such > an interaction might occur. > > In this particular case it just sounds like you need to open the file > without using O_CREAT if you intend to open an existing process owned > by another user, and if you intend to create a new file then you can > use O_CREAT and if the system call fails that is a feature and not a > bug. This safeguard forces the programmer to explicitly communicate > to the kernel if it intended to open an existing file owned by a > non-root user, vs getting tricked into it when it intended to create a > new one. You can catch the failure and try again with a different > name if you had wanted to create a temp file. > > -- > Rich > Excellent info Rich. Thanks! - Mark
Re: [gentoo-user] Re: Root can't write to files owned by others?
On Fri, Mar 11, 2022 at 1:23 PM Mark Knecht wrote: > > To me the overriding idea of not letting any user, including root, > mess around in a pipe makes logical sense, but as the OP has showed I > guess there were valid uses for this feature pre-patch, and it seems > that a user can override the feature by setting some bits if they need > to and really think they know what they are doing. There has been a long history of exploits on Unix involving places like /tmp because it is so easy for different users to step on each other's toes, possibly deliberately. The sorts of things that can go wrong are usually not intuitive, though anybody creating files in a world/group-writable location really should be aware of them. This is also the reason why you should never have "." in your path. Usually attacks work by predicting some file that a root-controlled process is about to create, and then creating it before the process does, so that the process ends up opening an existing file that you control instead of a new file that it controls. Programmers sometimes anticipate issues and create their own safeguards, but fail to understand race conditions so there can be a time gap between after the sanity checks are run and when the file is created. There is also a principle in security in general that suggests that any situation where data can pass between two different privilege levels needs to be safeguarded by default. I believe there are operating system models (probably including SELinux) that block such flows/transitions by default, and force programmers to explicitly define them so that they can't happen inadvertently. Basically if a non-privileged process can only interact with a privileged process via very tightly controlled APIs then it is much easier to secure the process, even if a programmer can't anticipate all the ways that such an interaction might occur. In this particular case it just sounds like you need to open the file without using O_CREAT if you intend to open an existing process owned by another user, and if you intend to create a new file then you can use O_CREAT and if the system call fails that is a feature and not a bug. This safeguard forces the programmer to explicitly communicate to the kernel if it intended to open an existing file owned by a non-root user, vs getting tricked into it when it intended to create a new one. You can catch the failure and try again with a different name if you had wanted to create a temp file. -- Rich
Re: [gentoo-user] Re: tensorflow-2.5.0-r1 compilation failed
On Fri, Mar 11, 2022 at 10:48 AM gevisz wrote: > > In addition to the old CPU, I have quite an old video card, > namely, ATI R4770. However, I still believe that it is possible > to compile tensorflow so that it could run on my hardware. > At least, I did it for tensorflow-2.7.0 on 21-11-2021. > Stay safe and return to us when you can. As for me I moved on and bought a new computer so my hardware issues with tensorflow are behind me for now. Cheers, Mark
Re: [gentoo-user] Re: Root can't write to files owned by others?
On Fri, Mar 11, 2022 at 10:06 AM Nikos Chantziaras wrote: > > On 11/03/2022 17:06, Mark Knecht wrote: > > Is this related to the 'dirty pipe' vulnerability that has been in the > > news of late and has gotten patched in most distros in the last few > > days? > > In one of the discussions about the patch, it was mentioned that "a > couple of CVEs would have never happened" if this had been the default > to begin with. So, probably yes? > > My Kubuntu system is set to '1' but Ubuntu released a patchset for 15 CVEs including the dirty pipe and I didn't even know about this feature before this news so I have no idea if this was just changed here but I suspect it was. I'm on a much older kernel than most of you guys. To me the overriding idea of not letting any user, including root, mess around in a pipe makes logical sense, but as the OP has showed I guess there were valid uses for this feature pre-patch, and it seems that a user can override the feature by setting some bits if they need to and really think they know what they are doing. Thanks for the response, Mark
Re: [gentoo-user] No sound. Please, help!
пн, 19 окт. 2020 г. в 00:15, gevisz : > > вс, 18 окт. 2020 г. в 21:15, Dale : > > > > gevisz wrote: > > > вс, 18 окт. 2020 г. в 17:20, Dale : > > >> gevisz wrote: > > >>> No sound at least in Firefox. Tried it on youtube. Skype is currently > > >>> uninstalled. So, I cannot check using it. > > >> Just a thought. Are you sure that everything is unmuted? Years ago, > > >> all the sound control software, Kmix, alsa and others, default to mute. > > >> If just one of them is muted, no sound. I seem to recall when I did my > > >> install on this rig that I had to unmute the sound in three places, > > >> Kmix, alsa and one other that I can't recall the name of. I think I had > > >> to turn up the volume on alsa as it was set to a really low level once > > >> it was unmuted. Usually, I turn all of them to the max except the one I > > >> mainly use. In my case, Kmix is the one I use to really control things > > >> since it sits on the panel thingy. The others are set at the max. > > >> > > >> It's a silly thing but thought it worth a mention just in case there is > > >> a muted setting somewhere. > > > Thank you for your input. Yes, it seems that something is muted but what? > > > I have no KDE and no kmix installed. No pulseaudio. > > > > Type in alsamixer in a console or whatever you use and hit tab twice. I > > suspect you have that installed. You should have a text version, like a > > console uses, and a gui version, that should work in any DM. Pick your > > poison and see if anything there is muted or the volume is set really > > low, like 1 out of 100 or something. I think hitting the "m" key > > toggles the mute. > > I am sorry to confess that I forgot that I should use M to unmute > a channel in alsamixer (as I did about 14 years ago) and thought > that arrows up and down do all the work. :( > > So, now the problem has been solved. Last time I have ended the discussion on my "no sound" problem acknowledging that I was so stupid that "forgot that I should use M to unmute a channel in alsamixer." However, it turned out that it was not the case: currently I have all channels in alsamixer unmuted and have sound only in about 1 from 10 bootings of my Gentoo system, while I do always have sound on the same computer while I boot it with Ubuntu 20.04. I have also compared the output of lsmod command on both systems and found out that my Gentoo system had all sound kernel modules that my Ubuntu system has and even more. (In Gentoo, I still have quite an old 5.4.97 kernel, but I do not think that it is the cause of my "no sound" problem.) Of course, it is completely my responsibility that I have built my Gentoo system in such a way that I never know if I will have sound after its next boot. However I am lost guessing what I did wrong. (Comparing with Ubuntu 20.04, my Gentoo system has no systemd and no pulseaudio, no consolekit, and no policykit.) I leave this just for history, as I am currently in a war zone and so investigating this problem further is not in my priority list. :(
Re: [gentoo-user] Re: tensorflow-2.5.0-r1 compilation failed
пн, 10 янв. 2022 г. в 18:16, Mark Knecht : > > > > > > Thank you for your reply, Mark. > > > > Unfortunately, you missed my previous message in this thread > > where I wrote that I do have Ubuntu 20.04 on the same computer. > > However, tensorflow fails to run on it because it is not compiled > > to be inconsistent with my videocard. So, Gentoo is my only option > > for this hardware. > > > > > My apologies. This thread has gone on for a while and I had to review > to get caught up. > > OK, so assuming I understand correctly (please correct me if I do > not) then you are talking about ONE computer that uses an AMD > Phenom II X4 processor. This computer dual boots, or is a Gentoo > machine with an Ubuntu VM. It is a dual boot. (Sorry for the late reply.) > In an earlier response to this thread you showed the flags > supported by this processor which did not include > the AVX, AVX2 or the FMA3/FMA4 flags. It is my > understanding that this processor cannot run the > current versions of tensorflow whether you compile > it yourself or not, at least in the non-GPU version. My hardware cannot run tensorflow precompiled by Ubuntu. However, some versions of tensorflow successfully compile and run in Gentoo: - all versions of tensorflow-2.5 fail to compile in Gentoo; - tensorflow-2.7.0 successfully compiled on 21-11-2021; - on 30-12-2021 recompilation of the same tensorflow-2.7.0 failed because of some changed dependencies; - I have not yet tried to compile tensorflow-2.8.0. Actually, I gave up trying to compile it and deleted it from my system. Moreover, I am not going to compile it in the near future as I am now in the war zone. > WRT to your video card, tensorflow does not require the use > of a GPU. There are two versions, tensorflow-cpu and > tensorflow-gpu. If you were to build the -cpu version then it > is my understanding it would run an a headless machine, > presuming the processor has AVX/AVX2/FMA hardware > support. > > If the processor DOES have AVX/FMA support but you were having > problems emerging TF in Gentoo then a virtual machine running > Ubuntu might have helped you as you could use a precompiled > apt or snap package. However I don't think anything gets you > past not having AVX/FMA hardware support. > > I am in the same situation. My big machine is an Intel i7 980 > Extreme. I used to be able to run TF but have not been able > to since Google raised the CPU requirements. > > If I am not understanding your hardware setup, or you think > there is a path around the AVX/FMA hardware problem > please let me know and I'll explore it more deeply with you. In addition to the old CPU, I have quite an old video card, namely, ATI R4770. However, I still believe that it is possible to compile tensorflow so that it could run on my hardware. At least, I did it for tensorflow-2.7.0 on 21-11-2021.
[gentoo-user] [NOTABUG] Re: Root can't write to files owned by others?
Greetings, On Wednesday, 2022-03-09 19:28:49 +0100, I myself wrote: > ... > until recently my system behaves sort of strangely: > >$ 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 >$ chmod a+w /tmp/file >$ ls -l /tmp/file >-rw--w--w- 1 rainer rainer 0 2022-03-09 19:06 /tmp/file >$ echo x | sudo tee /tmp/file >tee: /tmp/file: Permission denied >x >$ > > Since when can't root write to files it doesn't own? And not even, if > the file has write permission for everybody? Turns out it's not a bug but a feature, more precisely a security feat- ure. Its purpose is to prevent an unprivileged local user from luring user "root" into writing possibly sensitive information to an already existing file owned by and thus accessible to the local attacker. This protection feature was introduced as an option deactivated by def- ault way back in some 4.* kernel, and somewhere between kernels 5.15.19 and 5.15.26 the default was changed to on. If you want or have to, you can again disable this feature at runtime using # sysctl fs.protected_regular=0 or permanently from the next boot onwards via # echo fs.protected_regular = 0 >> /etc/sysctl.d/local.conf Personally, I've decided to again boot kernel 5.15.26, to leave the new default setting (even on my laptop), and to adapt my script which had problems with this new behaviour accordingly. Your milage may vary. Sincerely, Rainer
[gentoo-user] Re: Root can't write to files owned by others?
On 11/03/2022 17:06, Mark Knecht wrote: Is this related to the 'dirty pipe' vulnerability that has been in the news of late and has gotten patched in most distros in the last few days? In one of the discussions about the patch, it was mentioned that "a couple of CVEs would have never happened" if this had been the default to begin with. So, probably yes?
RE: [gentoo-user] Re: Root can't write to files owned by others?
>-Original Message- >From: Neil Bothwick >Sent: Friday, March 11, 2022 6:59 AM >To: gentoo-user@lists.gentoo.org >Subject: Re: [gentoo-user] Re: Root can't write to files owned by others? > >On Fri, 11 Mar 2022 12:38:48 +0100, Dr Rainer Woitok wrote: > >> No. My "/tmp/" directory is not mounted at all, it is just a genuine >> directory in "/". And that root CAN overwrite a file it doesn't own in >> other directories, is due to most directories not having the sticky >> bit set (which is a (wanted) particularity of "/tmp/" and >> "/var/tmp/", in that it prevents normal users from (re)moving other people's >> files): > >It's not the sticky bit per se from what I've read, but the new default >prevents root from overwriting a file if the file and the directory containing >it have different owners. In most cases, the file has the same directory as >the owner so this does not happen, but the sticky bit allows users that don't >own the directory to create files in it. > I was just looking at the patch. In at least one of its modes I think it's specifically looking for the sticky bit on the directory. I didn't think to pay attention to what the new default setting ends up doing for which specific mode it goes with. LMP
Re: [gentoo-user] Re: Root can't write to files owned by others?
On Fri, Mar 11, 2022 at 7:59 AM Neil Bothwick wrote: > > On Fri, 11 Mar 2022 12:38:48 +0100, Dr Rainer Woitok wrote: > > > No. My "/tmp/" directory is not mounted at all, it is just a genuine > > directory in "/". And that root CAN overwrite a file it doesn't own in > > other directories, is due to most directories not having the sticky bit > > set (which is a (wanted) particularity of "/tmp/" and "/var/tmp/", in > > that it prevents normal users from (re)moving other people's files): > > It's not the sticky bit per se from what I've read, but the new default > prevents root from overwriting a file if the file and the directory > containing it have different owners. In most cases, the file has the same > directory as the owner so this does not happen, but the sticky bit allows > users that don't own the directory to create files in it. > > > -- > Neil Bothwick > > Assassins do it from behind. Is this related to the 'dirty pipe' vulnerability that has been in the news of late and has gotten patched in most distros in the last few days? - Mark
Re: [gentoo-user] Re: Root can't write to files owned by others?
On Fri, 11 Mar 2022 12:38:48 +0100, Dr Rainer Woitok wrote: > No. My "/tmp/" directory is not mounted at all, it is just a genuine > directory in "/". And that root CAN overwrite a file it doesn't own in > other directories, is due to most directories not having the sticky bit > set (which is a (wanted) particularity of "/tmp/" and "/var/tmp/", in > that it prevents normal users from (re)moving other people's files): It's not the sticky bit per se from what I've read, but the new default prevents root from overwriting a file if the file and the directory containing it have different owners. In most cases, the file has the same directory as the owner so this does not happen, but the sticky bit allows users that don't own the directory to create files in it. -- Neil Bothwick Assassins do it from behind. pgpLaeAibxRPa.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: Root can't write to files owned by others?
Aho, On Friday, 2022-03-11 10:17:13 +0100, you wrote: > ... > I think Rainer's problem is the nosuid mount flag on his /tmp > > $ mount | grep \/tmp > tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime,size=3212160k,inode64) > > So if he would run the command against a file not located in /tmp I > think it would work, at least it does for me as it's only /tmp that has > nosuid. No. My "/tmp/" directory is not mounted at all, it is just a genuine directory in "/". And that root CAN overwrite a file it doesn't own in other directories, is due to most directories not having the sticky bit set (which is a (wanted) particularity of "/tmp/" and "/var/tmp/", in that it prevents normal users from (re)moving other people's files): $ ls -ld / /tmp /var/tmp drwxr-xr-x 21 root root 4096 2021-01-25 12:17 / drwxrwxrwt 10 root root 69632 2022-03-11 12:16 /tmp drwxrwxrwt 3 root root 4096 2022-03-10 10:23 /var/tmp $ ^ This "t" indicates a set sticky bit. Sincerely, Rainer
[gentoo-user] gnumeric export graph as image default settings?
I'm retired, and as a hobby I abstract the daily Ontario COVID stats and post them on DSLReports, e.g. https://www.dslreports.com/forum/r33351227- Gnumeric's "export graph as image option" has pain-in-the-butt defaults... 1) When exporting the first image during a gnumeric session its settings default to "Auto by extension" and 150 pixels per inch. I have to change it to 96 pixels per inch. 2) The second and subsequent exports will default to "SVG (Vector Graphics)" and the pixels per inch will stay at whatever I set it to the previous image, i.e. 96. Is there any way to set the defaults to something saner? Preferably "Auto by extension" and 96 pixels per inch so I don't have to do extra keystrokes every export? I "asked Mr. Google", but nothing helpful. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] Re: Root can't write to files owned by others?
On Friday, 11 March 2022 03:04:47 GMT Nikos Chantziaras wrote: > 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. ~ $ sysctl fs.protected_regular sysctl: permission denied on key 'fs.protected_regular' You're right about grep, but not about root. Anyway, I can confirm on kernel 5.15.23 fs.protected_regular is set to 0, while on 5.15.26 is it flipped to 1. signature.asc Description: This is a digitally signed message part.
