[Bug 238319] Proposal to extend an old feature and to create a completely new one

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238319

Bug ID: 238319
   Summary: Proposal to extend an old feature and to create a
completely new one
   Product: Base System
   Version: 11.3-STABLE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: j...@iki.fi

As already mentioned in the summary this is not actually a bug report per se,
but a proposal to extend the OS with completely new functionality.

- 1st I would like to propose making the session login name field sort of
write-once-read-many (WORM) field when kern.securelevel is above 0.
That would allow setting the login name once for each new session when
it has not been set before. Making it immutable when it has been set
would give he field content quite a lot credibility later for security
related actions or logging.

- 2nd I would like to propose adding a few completely new data items
in the session struct. These would be the address family and source address
for any IPC connections independent of whether it is LOCAL/UNIX or over
a proper network connection. Maybe even the protocol and source port should
be included when applicable. Obviously making such fields WORM similarly
to what I proposed for session login name above would be logical.
The benefit of having such address data available in a reliable manner
later in the session would make it very hard for any user or process to
hide the true origin of the session.
That would further allow for better security related decisions based
on where the session originates.
Maybe some services, their features, or actions should be limited purely
to local users, to users in a certain city, to users in a certain larger
geographic region, to users within a certain country, to users on a certain
continent, or maybe users from within any EU country but not others, etc.

In many cases the application server only inherits a local socket or a pty
from the actual network daemon. Without seeing the actual network socket
the child process has no access to the origin information available through
calls to getpeername() and getsockopt(). This then leads to weird attempts
to pass the true session origin to child processes in environment variables
(e.g SSH_CLIENT) or to other unreliable ad hoc methods to passing on the
information while leaving it in worst case modifiable to an intruder.

In some cases there might have to be distinct versions of the same service
provided to users from distinct origins. In some cases the difference might
be just a display of a different legal notification. In other cases there
might be additional features for users from a certain origin and reduced
features for other.

Number 2 above would naturally make the session struct quite large if
the longest possible local path name would have to fit in for LOCAL
domain origins. OTOH that increase would not cause a serious memory load
because there is only one session struct shared by all processes within
a session. From my point of view such relatively small sacrifice in memory
would be quite reasonable.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 238319] login: Extend and add features to session (struct)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238319

Kubilay Kocak  changed:

   What|Removed |Added

 Status|New |Open
   Severity|Affects Many People |Affects Some People
   Keywords||feature, needs-patch,
   ||security
Version|11.3-STABLE |CURRENT
Summary|Proposal to extend an old   |login: Extend and add
   |feature and to create a |features to session
   |completely new one  |(struct)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 233534] Panic on booting 12 on Jetway JNF9HG

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233534

j...@transactionware.com changed:

   What|Removed |Added

 CC||j...@transactionware.com

--- Comment #8 from j...@transactionware.com ---
For completeness, the underlying problem is fixed in r348539.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 238319] login: Extend and add features to session (struct)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238319

Conrad Meyer  changed:

   What|Removed |Added

 CC||c...@freebsd.org

--- Comment #1 from Conrad Meyer  ---
Re: (1):

s_login is only modified by setlogin(2), which requires PRIV_PROC_SETLOGIN,
which ... is always permitted for the current process on its session.  Each
time it is set, it produces an audit record, AUDIT_ARG_LOGIN().

You could conceivably add a flag to session 'has_login_been_set', set it as
appropriate, and check it in priv_check PRIV_PROC_SETLOGIN under securelevel. 
But why?

What does it mean to restrict setlogin(2) to "new" sessions?  Users can always
just create a new process and make it the new session leader (setsid() or
setpgid()).  The old process gets a new "login" on its associated session.

Re: (2):

I don't think this metadata makes much sense in session.  It's out of line with
existing session metadata (mostly tracking process group and controlling
terminal -- heavily tied to shell login and process groups).  In particular,
sessions are a process concept, not a thread one.  There is no guarantee that
all httpds follow the model required for this to make sense.

And if you have to fix httpds, you might as well just pass the information to
the worker in some side channel; either environment variables, or a pipe, or
shared memory segment.

I guess the target network daemon is sshd, which is single threaded, and for
that it might work?  But it doesn't really generalize, IMO.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 238324] Add XG-C100C/AQtion AQC107 10GbE NIC driver

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238324

Bug ID: 238324
   Summary: Add XG-C100C/AQtion AQC107 10GbE NIC driver
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: a...@mailbox.org

Add drivers for AQtion AQC107 chips and ASUS XG-C100C. 

Driver from AQN support:
https://www.dropbox.com/s/1j0ybm6nj8gj1n8/freebsd-drv-v0.0.2.zip?dl=0 

I got the link via a support ticket from the chipmaker (Aquantia). They told me
6 weeks ago that they are wokring on a driver. I just asked them for a update
today and the provided me with the link. On the driver
site(https://www.aquantia.com/support/driver-download/) its not up yet.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 205707] Improve parsing of BDFs by vtfontcvt

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205707

--- Comment #21 from commit-h...@freebsd.org ---
A commit references this bug:

Author: emaste
Date: Tue Jun  4 18:26:42 UTC 2019
New revision: 348653
URL: https://svnweb.freebsd.org/changeset/base/348653

Log:
  vtfontcvt: use VFNT_MAP_{NORMAL|BOL}_RH symbolic constants

  PR:   205707
  Reported by:  Dmitry Wagin
  MFC after:1 month

Changes:
  head/usr.bin/vtfontcvt/vtfontcvt.c

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 205707] Improve parsing of BDFs by vtfontcvt

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205707

--- Comment #22 from commit-h...@freebsd.org ---
A commit references this bug:

Author: emaste
Date: Tue Jun  4 18:31:52 UTC 2019
New revision: 348656
URL: https://svnweb.freebsd.org/changeset/base/348656

Log:
  vtfontcvt: unwrap a line per style(9)

  PR:   205707
  Submitted by: Dmitry Wagin

Changes:
  head/usr.bin/vtfontcvt/vtfontcvt.c

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 205707] Improve parsing of BDFs by vtfontcvt

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205707

--- Comment #23 from commit-h...@freebsd.org ---
A commit references this bug:

Author: emaste
Date: Tue Jun  4 18:49:49 UTC 2019
New revision: 348661
URL: https://svnweb.freebsd.org/changeset/base/348661

Log:
  vtfontcvt: rework height/width setting

  Introduce VFNT_MAXDIMENSION to replace bare 128, add set_height, and
  consistently use set_height and set_width.

  PR:   205707
  Submitted by: Dmitry Wagin

Changes:
  head/usr.bin/vtfontcvt/vtfontcvt.c

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 205707] Improve parsing of BDFs by vtfontcvt

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205707

Ed Maste  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|ema...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 238326] Kernel crash on jail stop (VIMAGE/VNET)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238326

Bug ID: 238326
   Summary: Kernel crash on jail stop (VIMAGE/VNET)
   Product: Base System
   Version: 12.0-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: paul.le.gau...@gmail.com

Jails managed through the native jails tools with the attached jail.conf file
(so called "thin jails", VNET). I can reliably crash the system by issuing a
"service jail restart". The crash happens when jails are being stopped.

[root@beastie ~]# uname -a
FreeBSD beastie 12.0-RELEASE-p4 FreeBSD 12.0-RELEASE-p4 GENERIC  amd64

[root@beastie ~]# service jail restart
Stopping jails: dns db ldap web nextcloud imap smtp testpacket_write_wait:
Connection to xxx.xxx.xxx.xxx port 22: Broken pipe


As a workaround I can avoid the crash by inserting a

exec.poststop = "sleep 2";

statement in jail.conf. 1 second was not enough to avoid the crash.

Also worth noting that the issue does not appear if I totally disable
networking, hence my guess this is somehow VIMAGE/VNET related.

I've managed to obtain a core dump but my attempts at debugging didn't go far
as I'm not experienced with this. Of course happy to do more debugging if this
can help identifying the issue. The system is not yet live so I can pretty much
try anything on it.

[root@beastie /var/crash]# kgdb /boot/kernel/kernel /var/crash/vmcore.0
GNU gdb (GDB) 8.2.1 [GDB v8.2.1 for FreeBSD]
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...(no debugging symbols found)...done.
0x80bcd0bd in sched_switch ()
(kgdb) bt
#0  0x80bcd0bd in sched_switch ()
#1  0x80ba6de1 in mi_switch ()
#2  0x80bf554c in sleepq_wait ()
#3  0x80ba6817 in _sleep ()
#4  0x80bfae71 in taskqueue_thread_loop ()
#5  0x80b5bf33 in fork_exit ()
#6  

My jail.conf file below. Note that the crash happens regardless of whether the
jails with special permissions (db, builder) are configured. I also tried
tweaking the mount/umount order without success.

$release="12.0-RELEASE"; # Release used to create the jail if not already
existing
host.hostname = "${name}";
path = "/jails/${name}";
exec.consolelog = "/var/log/jail.${name}.console.log";
vnet = "new";
vnet.interface = "epair${jailnum}b";
### Create the jail if not already exsisting ###
exec.prestart = "if [ ! -d "/jails/THINJAILS/${name}" ]; then zfs clone
zroot/jails/TEMPLATES/skeleton-${release}@skeleton
zroot/jails/THINJAILS/${name}; fi";
exec.prestart += "if [ ! -d "/jails/${name}" ]; then mkdir /jails/${name}; fi";
### Mount filesystems for shared base (RO) and individual jail skeleton (RW)
exec.prestart += "mount_nullfs -o ro /jails/TEMPLATES/base-${release}
/jails/${name}";
exec.prestart += "mount_nullfs -o rw /jails/THINJAILS/${name}/etc
/jails/${name}/etc";
exec.prestart += "mount_nullfs -o rw /jails/THINJAILS/${name}/home
/jails/${name}/home";
exec.prestart += "mount_nullfs -o rw /jails/THINJAILS/${name}/root
/jails/${name}/root";
exec.prestart += "mount_nullfs -o rw /jails/THINJAILS/${name}/tmp
/jails/${name}/tmp";
exec.prestart += "mount_nullfs -o rw /jails/THINJAILS/${name}/var
/jails/${name}/var";
exec.prestart += "mount_nullfs -o rw /jails/THINJAILS/${name}/usr/local
/jails/${name}/usr/local";
### Mount /usr/ports from hosts
exec.prestart += "mount_nullfs -o ro /usr/ports /jails/${name}/usr/ports";
### Mount data filesystem if exists
exec.prestart += "if [ -d "/jails/DATA/${name}" ]; then mount_nullfs -o rw
/jails/DATA/${name} /jails/${name}/data; fi";
### Mount devfs with the default ruleset (11) now that the jail filesystems are
mounted
exec.prestart += "mount -t devfs -o ruleset=4 devfs /jails/${name}/dev";
### Create an ethernet pair and add to bridge0 (internal bridge)
exec.prestart += "ifconfig epair${jailnum} create up";
exec.prestart += "ifconfig epair${jailnum}a description '${name} - host
interface'";
exec.prestart += "ifconfig epair${jailnum}b description '${name} - jail
interface'";
exec.prestart += "ifconfig bridge0 addm epair${jailnum}a";
exec.start = "ifconfig epair${jailnum}b inet 192.168.1.${jailnum}/24";
exec.start += "ifconfig epair

[Bug 83761] [panic] vm-related panic: blst_radix_free: freeing free block

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=83761

Kubilay Kocak  changed:

   What|Removed |Added

   Keywords||crash
   Assignee|b...@freebsd.org|a...@freebsd.org

--- Comment #10 from Kubilay Kocak  ---
Assign to committer that resolved.

^Triage: Not sure if this was MFC'd. If so, please set the correct mfc-stable*
flags to match

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"