#ttylogin — Public Fediverse posts

@ska

It's interesting how close but still how frustratingly far off #FreeBSD is in this regard.

The setlogin() name is per-session, not per-process. But whilst there is a sysctl() for snapshotting the process list, there isn't one for snapshotting the session list.

Apart from session objects lacking a creation timestamp and a "hostname", everything "who" needs is actually already maintained by the kernel, just inaccessibly.

https://github.com/freebsd/freebsd-src/blob/main/sys/sys/proc.h#L85

#ttylogin #utmps

@ska

It's interesting how close but still how frustratingly far off #FreeBSD is in this regard.

The setlogin() name is per-session, not per-process. But whilst there is a sysctl() for snapshotting the process list, there isn't one for snapshotting the session list.

Apart from session objects lacking a creation timestamp and a "hostname", everything "who" needs is actually already maintained by the kernel, just inaccessibly.

https://github.com/freebsd/freebsd-src/blob/main/sys/sys/proc.h#L85

#ttylogin #utmps

@ska

It's interesting how close but still how frustratingly far off #FreeBSD is in this regard.

The setlogin() name is per-session, not per-process. But whilst there is a sysctl() for snapshotting the process list, there isn't one for snapshotting the session list.

Apart from session objects lacking a creation timestamp and a "hostname", everything "who" needs is actually already maintained by the kernel, just inaccessibly.

https://github.com/freebsd/freebsd-src/blob/main/sys/sys/proc.h#L85

#ttylogin #utmps

@ska

I was pointing out on Hacker News how it had never really fully reconciled even pseudo-terminals into the design.

A better design of the "active logins" part would incorporate two observations:

1. For every login session there's some device in /dev that gets chown-ed to/is created by the user.

2. Really, kernel support is needed for a first-class session object; that can be enumerated. This idea has been knocking around since the 1980s, of course.

#utmps #ttylogin

@ska

I was pointing out on Hacker News how it had never really fully reconciled even pseudo-terminals into the design.

A better design of the "active logins" part would incorporate two observations:

1. For every login session there's some device in /dev that gets chown-ed to/is created by the user.

2. Really, kernel support is needed for a first-class session object; that can be enumerated. This idea has been knocking around since the 1980s, of course.

#utmps #ttylogin

@ska

I was pointing out on Hacker News how it had never really fully reconciled even pseudo-terminals into the design.

A better design of the "active logins" part would incorporate two observations:

1. For every login session there's some device in /dev that gets chown-ed to/is created by the user.

2. Really, kernel support is needed for a first-class session object; that can be enumerated. This idea has been knocking around since the 1980s, of course.

#utmps #ttylogin

@ska

I was pointing out on Hacker News how it had never really fully reconciled even pseudo-terminals into the design.

A better design of the "active logins" part would incorporate two observations:

1. For every login session there's some device in /dev that gets chown-ed to/is created by the user.

2. Really, kernel support is needed for a first-class session object; that can be enumerated. This idea has been knocking around since the 1980s, of course.

#utmps #ttylogin

@ska

I was pointing out on Hacker News how it had never really fully reconciled even pseudo-terminals into the design.

A better design of the "active logins" part would incorporate two observations:

1. For every login session there's some device in /dev that gets chown-ed to/is created by the user.

2. Really, kernel support is needed for a first-class session object; that can be enumerated. This idea has been knocking around since the 1980s, of course.

#utmps #ttylogin

@ska

DEAD_PROCESS is harder, as it's often written by the parent process on Linux. (On FreeBSD, the PAM session holder process declares itself dead, because pututxline() is called both ways within the pam_lastlog module.)

But it might be worth adding a check that a process really does not exist before a client (that isn't that very process declaring itself dead) can declare it to be dead.

#ttylogin #utmps

@ska

DEAD_PROCESS is harder, as it's often written by the parent process on Linux. (On FreeBSD, the PAM session holder process declares itself dead, because pututxline() is called both ways within the pam_lastlog module.)

But it might be worth adding a check that a process really does not exist before a client (that isn't that very process declaring itself dead) can declare it to be dead.

#ttylogin #utmps

@ska

DEAD_PROCESS is harder, as it's often written by the parent process on Linux. (On FreeBSD, the PAM session holder process declares itself dead, because pututxline() is called both ways within the pam_lastlog module.)

But it might be worth adding a check that a process really does not exist before a client (that isn't that very process declaring itself dead) can declare it to be dead.

#ttylogin #utmps

@ska

DEAD_PROCESS is harder, as it's often written by the parent process on Linux. (On FreeBSD, the PAM session holder process declares itself dead, because pututxline() is called both ways within the pam_lastlog module.)

But it might be worth adding a check that a process really does not exist before a client (that isn't that very process declaring itself dead) can declare it to be dead.

#ttylogin #utmps

@ska

DEAD_PROCESS is harder, as it's often written by the parent process on Linux. (On FreeBSD, the PAM session holder process declares itself dead, because pututxline() is called both ways within the pam_lastlog module.)

But it might be worth adding a check that a process really does not exist before a client (that isn't that very process declaring itself dead) can declare it to be dead.

#ttylogin #utmps

@ska

Preventing any client process upserting a USER_PROCESS record type for anything other than its own PID is probably a quite strong security check. More restrictive than group membership checks.

I checked util-linux's agetty and login, as a start. They only put their own PID in the process ID field. And they already look for an existing record to update by PID.

So it's an idea worth considering.

https://github.com/util-linux/util-linux/blob/master/login-utils/login.c#L1422

#ttylogin #utmps

@ska

Preventing any client process upserting a USER_PROCESS record type for anything other than its own PID is probably a quite strong security check. More restrictive than group membership checks.

I checked util-linux's agetty and login, as a start. They only put their own PID in the process ID field. And they already look for an existing record to update by PID.

So it's an idea worth considering.

https://github.com/util-linux/util-linux/blob/master/login-utils/login.c#L1422

#ttylogin #utmps

@ska

Preventing any client process upserting a USER_PROCESS record type for anything other than its own PID is probably a quite strong security check. More restrictive than group membership checks.

I checked util-linux's agetty and login, as a start. They only put their own PID in the process ID field. And they already look for an existing record to update by PID.

So it's an idea worth considering.

https://github.com/util-linux/util-linux/blob/master/login-utils/login.c#L1422

#ttylogin #utmps

@ska

Preventing any client process upserting a USER_PROCESS record type for anything other than its own PID is probably a quite strong security check. More restrictive than group membership checks.

I checked util-linux's agetty and login, as a start. They only put their own PID in the process ID field. And they already look for an existing record to update by PID.

So it's an idea worth considering.

https://github.com/util-linux/util-linux/blob/master/login-utils/login.c#L1422

#ttylogin #utmps

@ska

Preventing any client process upserting a USER_PROCESS record type for anything other than its own PID is probably a quite strong security check. More restrictive than group membership checks.

I checked util-linux's agetty and login, as a start. They only put their own PID in the process ID field. And they already look for an existing record to update by PID.

So it's an idea worth considering.

https://github.com/util-linux/util-linux/blob/master/login-utils/login.c#L1422

#ttylogin #utmps

@ska

https://news.ycombinator.com/item?id=43972744

Mentioning your work got me thinking.

Ignoring all of the boot/timechange/shutdown stuff, there are just 2 main pututxline() operations for utmp: upsert a USER_PROCESS record about the current process and write a DEAD_PROCESS record over the top of it.

Even on Linux, INIT_PROCESS and LOGIN_PROCESS are now junk; coming around to the situation as it has been on the BSDs all along.

#ttylogin #utmps

@ska

https://news.ycombinator.com/item?id=43972744

Mentioning your work got me thinking.

Ignoring all of the boot/timechange/shutdown stuff, there are just 2 main pututxline() operations for utmp: upsert a USER_PROCESS record about the current process and write a DEAD_PROCESS record over the top of it.

Even on Linux, INIT_PROCESS and LOGIN_PROCESS are now junk; coming around to the situation as it has been on the BSDs all along.

#ttylogin #utmps

@ska

https://news.ycombinator.com/item?id=43972744

Mentioning your work got me thinking.

Ignoring all of the boot/timechange/shutdown stuff, there are just 2 main pututxline() operations for utmp: upsert a USER_PROCESS record about the current process and write a DEAD_PROCESS record over the top of it.

Even on Linux, INIT_PROCESS and LOGIN_PROCESS are now junk; coming around to the situation as it has been on the BSDs all along.

#ttylogin #utmps

@ska

https://news.ycombinator.com/item?id=43972744

Mentioning your work got me thinking.

Ignoring all of the boot/timechange/shutdown stuff, there are just 2 main pututxline() operations for utmp: upsert a USER_PROCESS record about the current process and write a DEAD_PROCESS record over the top of it.

Even on Linux, INIT_PROCESS and LOGIN_PROCESS are now junk; coming around to the situation as it has been on the BSDs all along.

#ttylogin #utmps

@ska

https://news.ycombinator.com/item?id=43972744

Mentioning your work got me thinking.

Ignoring all of the boot/timechange/shutdown stuff, there are just 2 main pututxline() operations for utmp: upsert a USER_PROCESS record about the current process and write a DEAD_PROCESS record over the top of it.

Even on Linux, INIT_PROCESS and LOGIN_PROCESS are now junk; coming around to the situation as it has been on the BSDs all along.

#ttylogin #utmps