-----Original Message-----
From: Theo de Raadt [mailto:dera...@openbsd.org]
Sent: Saturday, November 10, 2018 7:57 PM
To: t...@uchicago.edu
Cc: misc@openbsd.org
Subject: Re: Change to init in -current?
Theodore Wynnychenko <t...@uchicago.edu> wrote:
> So, to do this, I edited the appropriate terminal line in /etc/ttys to a
custom
> entry defined in /etc/gettytab; then added an entry to /etc/gettytab, using
> 'lo:' to point to a ksh script which (basically) looks at the input given to
> getty, and if it contains a specific username, runs "/usr/bin/login -f root" -
> if the user name entered is something different, the ksh script runs -> exec
> /usr/bin/login "$@" <- which allows any other user to login with a password.
Yes it is the unveil of /usr/bin/login specifically, rather than the
variable 'LO' which is
gettytab.h:#define LO gettystrs[10].value
which is initialized by calling gettable() not just the first time,
but also later. That picks up the change, but it is too late it is
after unveil() has locked the filesystem space down.
So we'll need to consider softening the unveil position, or removing
the obscure feature which no longer works.
-----
I wanted to follow-up. I guess I am just looking to understand/clarify.
In the reply above, it states that the problem lies in the "unveil of
/usr/bin/login specifically."
Does this mean that getty is only allowed to access "/usr/bin/login," and that
my custom script is not in an allowed location after unveil "locks down" getty?
This seems to make sense to me. When I ran ktrace on the getty process that was
active for the local serial line, near the end of the trace (before the getty
session died and was re-spawned as a new/distinct process), I see:
...
55962 getty CALL getpid()
55962 getty RET getpid 55962/0xda9a
55962 getty CALL sendsyslog(0x7f7ffffbf2d0,64,0x2<LOG_CONS>)
55962 getty GIO fd -1 wrote 64 bytes
"<35>getty[55962]: /local/autologin.sh: No such file or directory"
55962 getty RET sendsyslog 0
55962 getty CALL kbind(0x7f7ffffc1338,24,0x6843e8d8b828be73)
55962 getty RET kbind 0
55962 getty CALL mprotect(0x15931882b000,0x1000,0x3<PROT_READ|PROT_WRITE>)
55962 getty RET mprotect 0
55962 getty CALL mprotect(0x15931882b000,0x1000,0x1<PROT_READ>)
55962 getty RET mprotect 0
55962 getty CALL mprotect(0x15931882b000,0x1000,0x3<PROT_READ|PROT_WRITE>)
55962 getty RET mprotect 0
55962 getty CALL mprotect(0x15931882b000,0x1000,0x1<PROT_READ>)
55962 getty RET mprotect 0
55962 getty CALL kbind(0x7f7ffffc1248,24,0x6843e8d8b828be73)
55962 getty RET kbind 0
55962 getty CALL mprotect(0x15931882b000,0x1000,0x3<PROT_READ|PROT_WRITE>)
55962 getty RET mprotect 0
55962 getty CALL mprotect(0x15931882b000,0x1000,0x1<PROT_READ>)
55962 getty RET mprotect 0
55962 getty CALL munmap(0x15931882b000,0x1000)
55962 getty RET munmap 0
55962 getty CALL exit(1)
----
Obviously, my script is named autologin.sh and lives in /local; and it does
exist with appropriate file permissions. It appears that getty does not have
access to it any longer. I surmise this error is because getty's filesystem
access has been locked down by unveil.
Is that what was meant by "unveil of /usr/bin/login specifically," or is it
something else?
Also, I am assuming that the only way I could correct this for myself would be
to learn a lot more of C than I know now, edit the getty source, and compile it
locally. In other words, there isn't something I can do from the command line
to get it to work again, is there?
Again, thanks. I totally understand that this functionality in getty may or may
not be available going forward.
Ted
