[Bug 265624] bin/pwd default behavior according to man page like -P but is like -L

2022-08-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265624

Bug ID: 265624
   Summary: bin/pwd default behavior according to man page like -P
but is like -L
   Product: Base System
   Version: 12.3-STABLE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: pascalullr...@web.de

FreeBSD 12.3-STABLE #1 r371380

>From man pwd:
"If no options are specified, the -P option is assumed."

My tests show that the  -L  option is assumed.

[ullrich@bsd106 ~/tmp]$ ls -l
total 4
drwxr-xr-x  2 ullrich  ullrich  512  3 Aug. 17:13 abc
lrwxr-xr-x  1 ullrich  ullrich3  3 Aug. 17:13 def -> abc
[ullrich@bsd106 ~/tmp]$ cd abc
[ullrich@bsd106 ~/tmp/abc]$ pwd
/home/ullrich/tmp/abc
[ullrich@bsd106 ~/tmp/abc]$ pwd -L
/home/ullrich/tmp/abc
[ullrich@bsd106 ~/tmp/abc]$ pwd -P
/home/ullrich/tmp/abc
[ullrich@bsd106 ~/tmp/abc]$ cd ../def
[ullrich@bsd106 ~/tmp/def]$ pwd
/home/ullrich/tmp/def
[ullrich@bsd106 ~/tmp/def]$ pwd -L
/home/ullrich/tmp/def
[ullrich@bsd106 ~/tmp/def]$ pwd -P
/home/ullrich/tmp/abc

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 265625] .zfs/snapshot directory is always readable (also by non-privileged users)

2022-08-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265625

Bug ID: 265625
   Summary: .zfs/snapshot directory is always readable (also by
non-privileged users)
   Product: Base System
   Version: 13.1-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: j...@magnetkern.de

The .zfs/snapshot directory of ZFS filesystems is always readable, also by
non-privileged users. Since it is impossible to change ownership or file modes
in a snapshot (it is read-only), this can be a security issue (only way to fix
a misconfiguration is to destroy all snapshots).

Moreover, the behavior may be unexpected to users since the .zfs directory is
hidden by default (but readable!).

There doesn't seem to be any way to disable access to snapshots (not even
globally for everyone). The only workaround I know is to use mount_nullfs to
shadow the directory. But that doesn't seem to be a clean solution and is error
prone.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 265625] .zfs/snapshot directory is always readable (also by non-privileged users)

2022-08-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265625

Anton Saietskii  changed:

   What|Removed |Added

 CC||vsasja...@gmail.com

--- Comment #1 from Anton Saietskii  ---
(In reply to jbe from comment #0)

If something is readable under .zfs/snapshot for someuser, then it was readable
on live dataset when the snapshot has been taken. Thus, I doubt if this a
snapdir issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 265625] .zfs/snapshot directory is always readable (also by non-privileged users)

2022-08-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265625

--- Comment #2 from j...@magnetkern.de ---
(In reply to Anton Saietskii from comment #1)

That is right. However file ownership and modes may change for two reasons:

1. They have been wrongly set.
2. They were correct but changed to harden security or otherwise reflect a
change of access privileges.

If old snapshots exists, then this allows (non-root) users to access data even
if files have been deleted or privileges have been revoked. I consider it a
potential security problem that revocation of privileges can't be enforced
(unless all snapshots from the past are deleted, which isn't always practical).

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 265594] It’s hard to know what version of FreeBSD you are running (primarily a documentation issue)

2022-08-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265594

Vinícius Zavam  changed:

   What|Removed |Added

 CC||egyp...@freebsd.org

--- Comment #1 from Vinícius Zavam  ---
would that help us a little bit?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251316 (Reported: 2020-11-22
16:59 UTC)

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 265626] permission

2022-08-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265626

Bug ID: 265626
   Summary: permission
   Product: Base System
   Version: 12.3-RELEASE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: misc
  Assignee: b...@freebsd.org
  Reporter: ugrolim...@bluewin.ch

hello  /etc/motd/  no permission  thanks for help

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 233098] can not find lua loader

2022-08-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233098

Mark Murray  changed:

   What|Removed |Added

 CC||ma...@freebsd.org
   Severity|Affects Only Me |Affects Many People

--- Comment #6 from Mark Murray  ---
This breaks installing FBSD on Macs under Parallels.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 265484] Adding INVARIANTS to GENERIC 13.1 kernel causes panic in mrsas

2022-08-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265484

--- Comment #6 from Mark Johnston  ---
(In reply to Terry Beck from comment #5)
Looking at the code, I'm pretty sure that the problem is still there in
stable/13, so I can't explain why it's not happening anymore.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 265632] sound: add patch for Lenovo Legion 5 Intel

2022-08-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265632

Bug ID: 265632
   Summary: sound: add patch for Lenovo Legion 5 Intel
   Product: Base System
   Version: CURRENT
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: edua...@freebsd.org

Hello,

I'm looking for speakers support on a Lenovo Legion 5 Intel (15IMH05) laptop.

 - headphones work ok
 - speakers doesn't produce sound.

A past review D30333 was incorporated into source but it doesn't make it work
on this laptop Intel version.

dmesg, sndstat and sysctl hdda logs at
https://people.freebsd.org/~eduardo/logs/speakers/

Thanks in advance,

Nuno Teixeira

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 264208] make install[kernel|world] from read only /usr/obj throws permission denied warnings.

2022-08-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264208

Jamie Landeg-Jones  changed:

   What|Removed |Added

 CC||ja...@catflap.org

--- Comment #3 from Jamie Landeg-Jones  ---
Have you tried testing with a non-NFS directory that you also don't have write
access to?

I'm only asking because on one of my new 13.1 machines, I get this (/usr/obj is
a standard directory, writeable only by root) - it seems for some reason, make
is trying to open the directory with write access, and failing (When I do it as
root, it obviously works [until I block roots write acesss], but "make" in that
case doesn't even attempt to actually write/create anything)

I don't get this warning on 13.0 and earlier. So maybe, NFS isn't actually
related to the issue - more the fact that make is now trying to test writing to
its obj dir?

As a non-root user:

% cd /

% make -v HOME
make warning: /usr/obj/: Permission denied.
/usr/users/jamie

As root:

# cd

# pwd
/root

# cd /

# make -v HOME
/root

# chflags schg /usr/obj
/usr/obj: 00 -> 040

# make -v HOME
make warning: /usr/obj/: Operation not permitted.
/root

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 265635] clang frontend command failed with exit code 139

2022-08-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265635

Bug ID: 265635
   Summary: clang frontend command failed with exit code 139
   Product: Base System
   Version: 13.1-RELEASE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: belltb_b...@proton.me

Created attachment 235686
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=235686&action=edit
code_generator-74cbda.sh build script

cc -pthread -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -O2
-pipe -fstack-protector-strong -fno-strict-aliasing -D_THREAD_SAFE -fPIC -I.
-Igrpc_root -Igrpc_root/include -Ithird_party/protobuf/src
-I/r/py3_venv/StarlinkRemote/include -I/usr/local/include/python3.9 -c
third_party/protobuf/src/google/protobuf/compiler/code_generator.cc -o
build/temp.freebsd-13.1-RELEASE-amd64-3.9/third_party/protobuf/src/google/protobuf/compiler/code_generator.o
-std=c++11
  PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include
the crash backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.Program arguments: /usr/bin/cc -pthread -Wno-unused-result
-Wsign-compare -Wunreachable-code -DNDEBUG -O2 -pipe -fstack-protector-strong
-fno-strict-aliasing -D_THREAD_SAFE -fPIC -I. -Igrpc_root -Igrpc_root/include
-Ithird_party/protobuf/src -I/r/py3_venv/StarlinkRemote/include
-I/usr/local/include/python3.9 -c
third_party/protobuf/src/google/protobuf/compiler/code_generator.cc -o
build/temp.freebsd-13.1-RELEASE-amd64-3.9/third_party/protobuf/src/google/protobuf/compiler/code_generator.o
-std=c++11
  1./usr/include/c++/v1/__utility/pair.h:183:9: current parser token ':'
  2./usr/include/c++/v1/__utility/pair.h:28:1
: parsing namespace 'std'
  3./usr/include/c++/v1/__utility/pair.h:28:1
: parsing namespace 'std::__1'
  4./usr/include/c++/v1/__utility/pair.h:42:1: parsing struct/union/class
body 'std::pair'
   #0 0x048a7860 (/usr/bin/cc+0x48a7860)
   #1 0x048a5cd5 (/usr/bin/cc+0x48a5cd5)
   #2 0x04842033 (/usr/bin/cc+0x4842033)
   #3 0x000805be8580 (/lib/libthr.so.3+0x1a580)
   #4 0x000805be7b3f (/lib/libthr.so.3+0x19b3f)
   #5 0x7fffe8a3 ([vdso]+0x2d3)
   #6 0x000805e877aa memcpy (/lib/libc.so.7+0x1577aa)
   #7 0x048a9651 (/usr/bin/cc+0x48a9651)
   #8 0x04849d33 (/usr/bin/cc+0x4849d33)
   #9 0x0238fef9 (/usr/bin/cc+0x238fef9)
  #10 0x0484a8fc (/usr/bin/cc+0x484a8fc)
  #11 0x0238f065 (/usr/bin/cc+0x238f065)
  #12 0x032e69f7 (/usr/bin/cc+0x32e69f7)
  #13 0x032e895f (/usr/bin/cc+0x32e895f)
  #14 0x032e777c (/usr/bin/cc+0x32e777c)
  #15 0x033ce5a5 (/usr/bin/cc+0x33ce5a5)
  #16 0x030db052 (/usr/bin/cc+0x30db052)
  #17 0x030a855b (/usr/bin/cc+0x30a855b)
  #18 0x030c31af (/usr/bin/cc+0x30c31af)
  #19 0x030c24c9 (/usr/bin/cc+0x30c24c9)
  #20 0x030a6421 (/usr/bin/cc+0x30a6421)
  #21 0x030a9855 (/usr/bin/cc+0x30a9855)
  #22 0x030a3861 (/usr/bin/cc+0x30a3861)
  #23 0x030a08c8 (/usr/bin/cc+0x30a08c8)
  #24 0x0307deec (/usr/bin/cc+0x307deec)
  #25 0x030c3449 (/usr/bin/cc+0x30c3449)
  #26 0x030c24c9 (/usr/bin/cc+0x30c24c9)
  #27 0x030c1e37 (/usr/bin/cc+0x30c1e37)
  #28 0x0307d165 (/usr/bin/cc+0x307d165)
  #29 0x030363c6 (/usr/bin/cc+0x30363c6)
  #30 0x03099a2b (/usr/bin/cc+0x3099a2b)
  #31 0x030995a2 (/usr/bin/cc+0x30995a2)
  #32 0x0307d3b0 (/usr/bin/cc+0x307d3b0)
  #33 0x030363c6 (/usr/bin/cc+0x30363c6)
  #34 0x03099a2b (/usr/bin/cc+0x3099a2b)
  #35 0x030995a2 (/usr/bin/cc+0x30995a2)
  #36 0x0307d1d0 (/usr/bin/cc+0x307d1d0)
  #37 0x030363c6 (/usr/bin/cc+0x30363c6)
  #38 0x03035157 (/usr/bin/cc+0x3035157)
  #39 0x03030edd (/usr/bin/cc+0x3030edd)
  #40 0x02b509b6 (/usr/bin/cc+0x2b509b6)
  #41 0x02ad68e6 (/usr/bin/cc+0x2ad68e6)
  #42 0x02bf3827 (/usr/bin/cc+0x2bf3827)
  #43 0x02215070 (/usr/bin/cc+0x2215070)
  #44 0x02221ac5 (/usr/bin/cc+0x2221ac5)
  #45 0x029ac907 (/usr/bin/cc+0x29ac907)
  #46 0x04841dca (/usr/bin/cc+0x4841dca)
  #47 0x029ac585 (/usr/bin/cc+0x29ac585)
  #48 0x0297f8e1 (/usr/bin/cc+0x297f8e1)
  #49 0x0297fd1f (/usr/bin/cc+0x297fd1f)
  #50 0x02992c8c (/usr/bin/cc+0x2992c8c)
  cc: error: clang frontend command failed with exit code 139 (use -v to see
invocation)
  FreeBSD clang version 13.0.0 (g...@github.com:llvm/llvm-project.git
llvmorg-13.0.0-0-gd7b669b3a303)
  Target: x86_64-unknown-freebsd13.1
  Thread model: posix
  InstalledDir: /usr/bin
  cc: note: diagnostic msg:
  

  PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
  Preprocessed source(s) and associa

[Bug 265635] clang frontend command failed with exit code 139

2022-08-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265635

--- Comment #1 from Tim Bell  ---
This happened while building 
   'grpc_tools._protoc_compiler' extension
deep inside 'pip3 install -vvv -r src/python/requirements.txt' for this
project: https://github.com/jim-olsen/StarlinkRemote

The source file /tmp/code_generator-74cbda.cpp is 7.9MBytes, so it is too large
to attach here.
I can provide it offline if useful.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 265626] permission

2022-08-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265626

Graham Perrin  changed:

   What|Removed |Added

 CC||grahamper...@gmail.com

--- Comment #1 from Graham Perrin  ---
ls -dhl /etc/motd

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 265635] clang frontend command failed with exit code 139

2022-08-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265635

--- Comment #2 from Tim Bell  ---
% /usr/bin/cc --version
FreeBSD clang version 13.0.0 (g...@github.com:llvm/llvm-project.git
llvmorg-13.0.0-0-gd7b669b3a303)
Target: x86_64-unknown-freebsd13.1
Thread model: posix
InstalledDir: /usr/bin

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 265625] .zfs/snapshot directory is always readable (also by non-privileged users)

2022-08-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265625

Graham Perrin  changed:

   What|Removed |Added

 CC||grahamper...@gmail.com

--- Comment #3 from Graham Perrin  ---
> 13.1-RELEASE 

Please join the discussion in the OpenZFS area: 

.zfs/snapshots privileges settings · Discussion #9028 · openzfs/zfs


-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 265598] page fault under fork in kernel

2022-08-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265598

Graham Perrin  changed:

   What|Removed |Added

 CC||grahamper...@gmail.com

--- Comment #1 from Graham Perrin  ---
Reproducible with 12.3-RELEASE-p5?

(In reply to heas from comment #0)

> 12.2, currently at p15.

12.2-RELEASE reached end of life a few months ago. 



-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 265594] It’s hard to know what version of FreeBSD you are running (primarily a documentation issue)

2022-08-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265594

Graham Perrin  changed:

   What|Removed |Added

 CC||grahamper...@gmail.com

--- Comment #2 from Graham Perrin  ---
(In reply to Robert Watson from comment #0)

NAME
 freebsd-update – fetch and install binary updates to FreeBSD

…

DESCRIPTION
 The freebsd-update tool is used to fetch, install, and rollback binary
 updates to the FreeBSD base system.

…


Given the name and description (above), I think that telling the version alone
– _without_ any update-related action – is out of scope for freebsd-update(8). 

> … no way to print the current version …

The version and patch level can be found in response to: 

freebsd-update fetch



root@fuji:~ # freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching metadata signature for 13.1-RELEASE from update1.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 13.1-RELEASE-p0.
root@fuji:~ # freebsd-version -kru
13.1-RELEASE
13.1-RELEASE
13.1-RELEASE
root@fuji:~ #

-- 
You are receiving this mail because:
You are the assignee for the bug.