[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[SCM] Hurd branch, master, updated. v0.9.git20220301-46-g011c6ea6
|
From: |
Samuel Thibault |
|
Subject: |
[SCM] Hurd branch, master, updated. v0.9.git20220301-46-g011c6ea6 |
|
Date: |
Wed, 10 Aug 2022 16:26:29 -0400 (EDT) |
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Hurd".
The branch, master has been updated
via 011c6ea6d9a4c5a61cd1a190eb48a0e4adb13aed (commit)
via e6c258d00582258ffd0448ad5d6a6ef0d3926cf6 (commit)
via a8a9ad7f6a298ac3f669fc18bb17005e48524c01 (commit)
via 5710aaa670a14cbbe4da0e8fe64314a55f14a015 (commit)
via b6c6e41a0d94740f4ecce9afdafa0c17348ce4c0 (commit)
via 2e3a1e0f028ae5498d96a4a3618a3533e062d2eb (commit)
via ffead1cbcaa1db5db525403043e27d618af8752b (commit)
via 281396c87082d7d09a651c5f614cf3767dcc15e3 (commit)
via fb59c57316054d84f64d3bd35072ac92d51f9419 (commit)
via 008a7e92c54c2f71f282527241d18875be61ecf3 (commit)
via 3c9f1482b6890cfed89880e728ec6114e37c33d4 (commit)
via 29e3f1804c28cdcef6d130cf4c426fd40d10197b (commit)
via 386d55dd471accafea06502c74e67de0ceb3351d (commit)
via 865e37787d2331d2d5b18a8cfaa31ba7bec9f71b (commit)
via 32b545a5d29cb3b6caa1bca6c8d21a1e0781a12d (commit)
via f2f97b426b0df1896165aebb286a26bcb81a0784 (commit)
via 70db307adda765729913eaf355077faa78c5caaf (commit)
via ccc7705774918e4ae5367c3e8931765807e3931d (commit)
via a7e36189261bc1a8dc08744cea976c88fbe4c27c (commit)
via f589b48217e6593714e80e2a043fb8fd382acff8 (commit)
via 9284ddfd23fe4c328e4ff4243780e2e9c691390b (commit)
via 005fe822cbdacc398c7a47540078188a383574db (commit)
via f10886297e77091b7bc313766cf7c8bac97d4291 (commit)
via b24812dce9062559ab2b9a3d07505d9985ccc83a (commit)
via b948c942539d47fb91a28dd085a028f3116b70c4 (commit)
via 612674f4b77472c381c8150138fce8a34a4c9119 (commit)
via 4b739a627e08fe0bc50342e65ba61abd0152fe17 (commit)
via 99df125e1048d9d09cfb68ce54725a089bacc140 (commit)
via a239719cd41e2c409366570f84639fa4a322c88b (commit)
via 111e1a54234613eb5055903cffa20d1f1e6a659e (commit)
via 2c6c2b011eda70abac23c6ff9702917485f9ed3b (commit)
via 009ef29d60bb83dd6fdaeb647e27b3e0e385a733 (commit)
via cbe5af61970052429388737de19dbc7ad03ffa96 (commit)
via 8db6b70ab6a64ea9b0ac313f2816131a046fbd76 (commit)
via 3e62adfb214090de7ad531d3aa68570aae92f9ec (commit)
via 7360a092712ad01c5803901df5ca6e0edef4150f (commit)
via 9393fb33d0405cfb99449241139413f0aae6f4f0 (commit)
via b14e0100f5295abd950eef636fa16df181504401 (commit)
via 7c3323a25bc1d5844feb7f9ed241fdbdb4819739 (commit)
via 1ed64a8674d3359822831d4ac9a016c04d3e8b14 (commit)
via 736c90333e887da5215e3c8a0bb489342b5fd23c (commit)
via ff0487ddf0ba1f98daef8265eb3a50b1570b8f41 (commit)
via 033397a36ab5bf40d7184791e036fae781355a21 (commit)
via b15326a788615988df10d4f2dbe39190126135d6 (commit)
from 88ee4ae44bd64e869bca79d0a6c6e6d4577b7170 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 011c6ea6d9a4c5a61cd1a190eb48a0e4adb13aed
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Wed Aug 10 22:20:36 2022 +0200
Rename proc_complete_reauthentication to proc_reauthenticate_complete
For coherency with the existing RPCs
commit e6c258d00582258ffd0448ad5d6a6ef0d3926cf6
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Wed Aug 10 22:19:56 2022 +0200
Keep proc_setowner_request for backward compatibility
So that existing callers can still compile, and just get MIG_BAD_ID.
commit a8a9ad7f6a298ac3f669fc18bb17005e48524c01
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Wed Aug 10 22:17:53 2022 +0200
Fix including notify_S.h and running ports_notify_server_routine
commit 5710aaa670a14cbbe4da0e8fe64314a55f14a015
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Wed Jun 9 15:41:58 2021 +0300
Make proc_reauthenticate () recreate proc port
And add proc_complete_reauthentication ()
commit b6c6e41a0d94740f4ecce9afdafa0c17348ce4c0
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Sun May 30 13:16:30 2021 +0300
libnetfs, libtrivs: Shield S_file_exec_paths () from cancellation
Here's the sequence of events that leads to a bug:
* A task calls file_exec_paths () on itself, holding the only send right to
the
protid, passing EXEC_NEWTASK (or EXEC_SECURE, which implies it).
* S_file_exec_paths () calls exec_exec_paths ()
* The exec server sets up a new task and calls proc_reassign () or
proc_reauthenticate_reassign ().
* The proc server destroys the old task, and the only send right to the
protid
with it.
* The translator gets a no-senders notification, which results in a
ports_interrupt_rpcs () call on the S_file_exec_paths ().
* This propagates to the exec server (and potentially proc and auth
servers).
* The exec gets canceled, and the new task gets killed.
In my opinion, the party that seems most guilty is the translator canceling
exec
upon receiving a no-senders notification for the protid. Normally, a
no-senders
notification means that the caller is no longer interested in the RPC, but
this
is not true in case of exec.
To work around this, create an additional send right to the protid.
commit 2e3a1e0f028ae5498d96a4a3618a3533e062d2eb
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Sat May 29 18:08:52 2021 +0300
Remove the concept of process owner
Now that it's completely unused.
procinfo.owner is now simply set to the first UID that a process has.
proc_setowner () is kept for compatibility, but now does nothing.
The clients still try to call it, though, for compatibility with older
proc server versions.
commit ffead1cbcaa1db5db525403043e27d618af8752b
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Sat May 29 17:56:38 2021 +0300
libshouldbeinlibc: Do not reauthenticate proc port when secure
exec_reauth () is supposed to reauthenticate the given ports and file
descriptors with a new authentication. If the secure flag is set, this
reauthentication is happening for a future exec with the EXEC_SECURE
flag.
Now that the exec server uses proc_reauthenticate_reassign (), the process
reauthentication is done atomically with task reassignment by the exec
server. So stop doing it inside exec_reauth ().
This fixes a vulnerability where a process was able to use its
reauthenticated proc port before it got exec'ed over.
commit 281396c87082d7d09a651c5f614cf3767dcc15e3
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Sat May 29 17:53:56 2021 +0300
exec: Use proc_reauthenticate_reassign ()
This lets the exec server atomically replace the old task with the new task
while raising its privileges.
commit fb59c57316054d84f64d3bd35072ac92d51f9419
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Sat May 29 17:50:52 2021 +0300
proc: Add proc_reauthenticate_reassign ()
This is a new RPC to atomically change the UIDs of a process, recreate its
process port, and reassign a different task to it.
commit 008a7e92c54c2f71f282527241d18875be61ecf3
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Sat May 29 17:07:24 2021 +0300
proc: Fix an error path
If the allocation failed, we want to leave the p_ids pointer as it was, and
properly propagate the error code.
commit 3c9f1482b6890cfed89880e728ec6114e37c33d4
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Sat May 29 16:36:53 2021 +0300
proc: Use UIDs for evaluating permissions
The previous scheme was to check that PROC1 has the UID that is designated
as PROC2's "owner". This is extremely problematic for several reasons,
including:
* The UIDs and the owner of a process are set separately and can easily get
out
of sync. While S_proc_setowner () checks that the new owner is among the
UIDs
that the process has, this invariant is violated after the process is
given a
new set of UIDs with S_proc_reauthenticate (). In particular, this happens
during execution of a SUID binary: the process is reauthenticated to a
different set of UIDs first, and its owner is udpated later, if at all.
* In the Hurd, a process can have multiple UIDs. Having to designate just
one
of them as the owner means the other UIDs get ignored for the purpose of
permission checking. One particularly problematic case is a SUID process
that
temporarily lowers its effective UID: glibc sets the first effective UID
as
the process owner, giving just about anyone access to the task.
Resolve this by ignoring the owner for the purpose of permission checking,
and
relying solely on the authenticated UIDs. Roughly speaking, PROC1 can get
complete access to PROC2 if the UIDs PROC1 has form a superset of the UIDs
that
PROC2 has; in other words, the access is only allowed when it would not
result
in PROC1 getting access to UIDs it doesn't have already. Of course, root is
still allowed to access any process.
In particular, this means that:
* a process can access another process if they have the same auth;
* a process that has "more auth" can access one that has "less auth", but
not
the other way around;
* a SUID-root process that has lowered its effective UIDs can only be
accessed
by root.
Another important point here is that the UIDs in question are both effective
and available UIDs that a process has. Normally, available UIDs are ignored
for
the purpose of permission checking (and that is their whole point). However,
POSIX description of kill(2) has the following clause:
> For a process to have permission to send a signal to a process designated
by
> pid, unless the sending process has appropriate privileges, the real or
> effective user ID of the sending process shall match the real or saved
> set-user-ID of the receiving process.
Which I read as saying that the real (i.e. available) UID(s) of PROC1
should be
used for evaluating whether kill(2) can succeed, not only its effective
UID(s).
commit 29e3f1804c28cdcef6d130cf4c426fd40d10197b
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Sat May 29 16:28:46 2021 +0300
proc: Track both available and effective uids
This is in preparation for using the UID's to evaluate permissions
in a different way.
commit 386d55dd471accafea06502c74e67de0ceb3351d
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Sat May 29 17:32:13 2021 +0300
libfshelp: Handle proc port in fshelp_start_translator_long ()
While fshelp_start_translator_long () has been calling proc_setowner () on
the
task it creates, it has never reauthenticated its process. This meant that
the
translator, once started, could access processes authenticated same as the
process that called fshelp_start_translator_long (). In particular, this
means
that any unprivileged translator started by a privileged parent translator
had
in fact had a privileged proc port, and could access other processes through
it.
With this change, fshelp_start_translator_long () will now reauthenticate
the
process it creates. Moreover, it will now respect a custom proc server port
passed in the given ports.
commit 865e37787d2331d2d5b18a8cfaa31ba7bec9f71b
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Sat May 29 17:24:38 2021 +0300
libfshelp: Cosmetic cleanups
commit 32b545a5d29cb3b6caa1bca6c8d21a1e0781a12d
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Sat May 29 17:20:29 2021 +0300
libfshelp: Simplify fshelp_start_translator_long () a bit
It only really supports ports_len > INIT_PORT_BOOTSTRAP,
ports_type == MACH_MSG_TYPE_COPY_SEND, fds_type == MACH_MSG_TYPE_COPY_SEND.
Make that explicit, and remove the branches that tried to handle the other
cases.
commit f2f97b426b0df1896165aebb286a26bcb81a0784
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Wed May 26 20:07:52 2021 +0300
startup: Request notifications to a separate port
Since this port is never given out to anyone but the kernel,
our clients can't spoof a dead-name notification this way.
commit 70db307adda765729913eaf355077faa78c5caaf
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Thu Aug 5 19:18:03 2021 +0300
console: Forward any libports-requested notifications to them
libports will start requesting dead-name notifications on its own.
As we handle all notifications, both ones we have requested and ones
libports has, distinguish between the two handlers by the port.
commit ccc7705774918e4ae5367c3e8931765807e3931d
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Wed May 26 19:19:36 2021 +0300
console: Return EOPNOTSUPP when appropriate
We do not impement most of the mach_notify_* () routines. Explicitly return
an error code so that our caller knows to properly deallocate all resources
the messages may carry.
Even though we don't expect to receive some of the notifications from the
kernel
as we never sign up for them, we can always receive spoofed notifications
from
our clients, so don't abort in that case.
commit a7e36189261bc1a8dc08744cea976c88fbe4c27c
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Thu Aug 5 19:12:42 2021 +0300
console: Simplify code with ports_request_dead_name_notification ()
We can't use it to *request* notifications here, since we need to use
a custom per-display port (and not libports' notify_port), but we can
still use it to *cancel* notifications with a lot less boilerplate.
commit f589b48217e6593714e80e2a043fb8fd382acff8
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Thu Aug 5 19:25:42 2021 +0300
libports: Only accept dead-name notifications on notify_port
Since this port is never given out to anyone but the kernel,
our clients can't spoof a dead-name notification this way.
commit 9284ddfd23fe4c328e4ff4243780e2e9c691390b
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Wed May 26 18:05:40 2021 +0300
libports: Return EOPNOTSUPP when appropriate
We do not impement most of the mach_notify_* () routines. Explicitly return
an error code so that our caller knows to properly deallocate all resources
the messages may carry.
commit 005fe822cbdacc398c7a47540078188a383574db
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Wed May 26 16:44:17 2021 +0300
libmachdev: Use notify server implementation from libports
Since the implementation in libmachdev was just forwarding calls
to the corresponding libports functions, we might as well just use
ports_notify_server_routine () directly.
commit f10886297e77091b7bc313766cf7c8bac97d4291
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Wed May 26 17:28:18 2021 +0300
libdiskfs, libnetfs: Disable broken code
This logic is obviously broken, let's disable it for now.
commit b24812dce9062559ab2b9a3d07505d9985ccc83a
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Wed May 26 17:25:33 2021 +0300
libfshelp: Update some comments
commit b948c942539d47fb91a28dd085a028f3116b70c4
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Thu Aug 5 18:51:16 2021 +0300
diskfs: Use libports notifications
Namely, ports_request_dead_name_notification () where we can,
and the libports notify port when we have to pass it to libfshelp.
commit 612674f4b77472c381c8150138fce8a34a4c9119
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Thu Aug 5 18:16:42 2021 +0300
netfs: Use the libports notify port
commit 4b739a627e08fe0bc50342e65ba61abd0152fe17
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Thu Aug 5 18:03:47 2021 +0300
eth-multiplexer: Use notify server implementation from libports
We can simply override proc_dead_name () to handle dead-name notifications.
commit 99df125e1048d9d09cfb68ce54725a089bacc140
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Thu Aug 5 17:57:45 2021 +0300
eth-multiplexer: Use ports_request_dead_name_notification ()
commit a239719cd41e2c409366570f84639fa4a322c88b
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Thu Aug 5 17:37:50 2021 +0300
proc: Use notify server implementation from libports
We can simply override proc_dead_name () to handle dead-name notifications.
commit 111e1a54234613eb5055903cffa20d1f1e6a659e
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Wed May 26 16:40:47 2021 +0300
proc: Use ports_request_dead_name_notification ()
commit 2c6c2b011eda70abac23c6ff9702917485f9ed3b
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Thu Aug 5 18:36:30 2021 +0300
libports: Add ports_request_dead_name_notification ()
This significantly cuts down the boilerplate of
requesting dead-name notifications.
commit 009ef29d60bb83dd6fdaeb647e27b3e0e385a733
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Thu Aug 5 16:58:20 2021 +0300
libports: Request notifications to the notify_port
commit cbe5af61970052429388737de19dbc7ad03ffa96
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Thu Aug 5 16:47:08 2021 +0300
libports: Create a notify_port in each bucket
This notify port will be used to request & receive Mach notifications.
While it is present in the bucket much like any other port, it is not
counted in ports_count_bucket () and is not exposed to the user
callback in ports_bucket_iterate ().
commit 8db6b70ab6a64ea9b0ac313f2816131a046fbd76
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Wed May 26 17:42:07 2021 +0300
libports: Treat no-senders notifications as a hint
No-senders notifications are directed to the port that no longer has any
senders left. Since any client can easily spoof such a notification, we
have to
treat the notification as just a hint and verify whether there are, in fact,
any senders, and only call ports_no_senders () if there actually are none
left.
commit 3e62adfb214090de7ad531d3aa68570aae92f9ec
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Wed May 26 16:30:53 2021 +0300
proc: Drop some mach_port_destroy () uses
mach_port_destroy () is a dangerous API that has to be used with extreme
care.
Namely, it destroys not one user reference, but *all* user references that a
task has for a port name. Different parts of a program may all keep separate
references on a port without coordinating it with each other (which is the
whole idea behind reference counting). If one part of a program decides to
destroy a port with mach_port_destroy () without informing others, others
may
still believe they hold a reference and will continue to use the name as if
it
still refered to the now-destroyed port right. This consitutes a port
use-after-free, even if their use is also deallocating their reference.
In the particular case of the proc server, this manifested itself as
S_proc_reassign () destroying all user references to the task port right
before
the task port right is deallocated again in the dead-name notification
handler.
commit 7360a092712ad01c5803901df5ca6e0edef4150f
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Wed May 26 15:36:28 2021 +0300
Do not use ports_get_right () for send-one rights
ports_get_right () expects the caller to make a send, not a send-once,
right from the returned receive right, and increments the expected make-send
count accordingly. The kernel, however, does not increment the make-send
count when a send-once right is being made.
The result can be described as a "no-senders leak": libports' idea of the
current make-send count always stays one step ahead of it actual value (or
several steps ahead, if the process is repeated), which makes libports
ignore *all* the subsequent no-senders notifications for the port as
outdated.
commit 9393fb33d0405cfb99449241139413f0aae6f4f0
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Wed Aug 10 22:11:11 2022 +0200
Update to the improved memory_object_create proxy RPC
Thus avoiding two RPCs.
commit b14e0100f5295abd950eef636fa16df181504401
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Wed Aug 10 22:05:09 2022 +0200
Do not cache the R/O proxy
We cannot properly detect when to release the ro_proxy, so let's just not
cache it.
commit 7c3323a25bc1d5844feb7f9ed241fdbdb4819739
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Fri May 21 13:21:15 2021 +0300
tmpfs: Return read-only memory objects when appropriate
commit 1ed64a8674d3359822831d4ac9a016c04d3e8b14
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Fri May 21 13:00:51 2021 +0300
fatfs: Return read-only memory objects when appropriate
commit 736c90333e887da5215e3c8a0bb489342b5fd23c
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Fri May 21 12:54:13 2021 +0300
ext2fs: Return read-only memory objects when appropriate
commit ff0487ddf0ba1f98daef8265eb3a50b1570b8f41
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Wed May 19 18:14:37 2021 +0300
libpager: Add pager_get_ro_port ()
A pager will now maintain a port to a read-only memory object proxy
for itself, and let the users access it with pager_get_ro_port ().
commit 033397a36ab5bf40d7184791e036fae781355a21
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Fri May 21 13:35:11 2021 +0300
isofs: Assert we're only supposed to provide a read-only pager
commit b15326a788615988df10d4f2dbe39190126135d6
Author: Sergey Bugaev <bugaevc@gmail.com>
Date: Fri May 21 12:56:19 2021 +0300
fatfs: Properly reference pager
A node keeps a weak reference on the pager as long as
diskfs_node_disknode (node)->pager points to it. A pager keeps a light
reference on the node as long as the UPI is alive.
This is the same way it's done in ext2fs.
-----------------------------------------------------------------------
Summary of changes:
console/display.c | 42 +--
eth-multiplexer/Makefile | 4 +-
devnode/util.h => eth-multiplexer/dead-name.c | 32 +--
eth-multiplexer/device_impl.c | 14 +-
eth-multiplexer/mig-mutate.h | 9 -
eth-multiplexer/multiplexer.c | 11 +-
eth-multiplexer/notify_impl.c | 69 -----
exec/exec.c | 82 +++---
ext2fs/pager.c | 69 ++---
fatfs/pager.c | 104 +++----
hurd/process.defs | 31 +-
hurd/process_reply.defs | 7 +-
hurd/process_request.defs | 17 +-
isofs/pager.c | 3 +
libdiskfs/dead-name.c | 7 +-
libdiskfs/dir-lookup.c | 4 +-
libdiskfs/file-exec.c | 4 +-
libdiskfs/file-set-trans.c | 3 +-
libdiskfs/ifsock.c | 10 +-
libdiskfs/node-drop.c | 1 +
libfshelp/exec-reauth.c | 22 +-
libfshelp/start-translator-long.c | 160 +++++++----
libfshelp/translator-list.c | 3 +-
libmachdev/Makefile | 2 +-
libmachdev/ds_routines.c | 4 +-
libmachdev/trivfs_server.c | 46 +--
libnetfs/dead-name.c | 5 +
libnetfs/dir-lookup.c | 5 +-
libnetfs/file-exec.c | 4 +-
libnetfs/file-set-translator.c | 3 +-
libpager/Makefile | 2 +-
.../io-get-conch.c => libpager/pager-ro-port.c | 46 +--
libpager/pager.h | 4 +
libports/Makefile | 2 +-
libports/bucket-iterate.c | 5 +-
libports/count-bucket.c | 11 +-
libports/create-bucket.c | 23 ++
libports/interrupt-on-notify.c | 8 +-
libports/notify-dead-name.c | 4 +-
libports/notify-msg-accepted.c | 2 +-
libports/notify-no-senders.c | 23 +-
libports/notify-port-deleted.c | 2 +-
libports/notify-port-destroyed.c | 2 +-
libports/notify-send-once.c | 2 +-
libports/ports.h | 21 ++
libports/request-notification.c | 54 ++++
libshouldbeinlibc/exec-reauth.c | 34 +--
proc/Makefile | 9 +-
libfshelp/lock-init.c => proc/dead-name.c | 32 ++-
proc/host.c | 12 +-
proc/info.c | 47 ++-
proc/main.c | 4 +-
proc/mgt.c | 314 ++++++++++++++++-----
proc/mig-mutate.h | 9 -
proc/notify.c | 106 -------
proc/proc.h | 2 -
startup/startup.c | 30 +-
tmpfs/node.c | 28 +-
tmpfs/tmpfs.h | 2 +-
utils/login.c | 1 +
60 files changed, 902 insertions(+), 716 deletions(-)
copy devnode/util.h => eth-multiplexer/dead-name.c (68%)
delete mode 100644 eth-multiplexer/notify_impl.c
copy libdiskfs/io-get-conch.c => libpager/pager-ro-port.c (51%)
create mode 100644 libports/request-notification.c
copy libfshelp/lock-init.c => proc/dead-name.c (54%)
delete mode 100644 proc/notify.c
hooks/post-receive
--
Hurd
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [SCM] Hurd branch, master, updated. v0.9.git20220301-46-g011c6ea6,
Samuel Thibault <=