Re: Change to init in -current?
Theodore Wynnychenko wrote: > 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? yes. > 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? yes. > 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? yes. the C involved is actually very rudimentary. just look for calls to unveil in the source. the downside is this isn't likely to be a change taken back.
Re: Change to init in -current?
-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 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 gettyCALL getpid() 55962 gettyRET getpid 55962/0xda9a 55962 gettyCALL sendsyslog(0x7f7bf2d0,64,0x2) 55962 gettyGIO fd -1 wrote 64 bytes "<35>getty[55962]: /local/autologin.sh: No such file or directory" 55962 gettyRET sendsyslog 0 55962 gettyCALL kbind(0x7f7c1338,24,0x6843e8d8b828be73) 55962 gettyRET kbind 0 55962 gettyCALL mprotect(0x15931882b000,0x1000,0x3) 55962 gettyRET mprotect 0 55962 gettyCALL mprotect(0x15931882b000,0x1000,0x1) 55962 gettyRET mprotect 0 55962 gettyCALL mprotect(0x15931882b000,0x1000,0x3) 55962 gettyRET mprotect 0 55962 gettyCALL mprotect(0x15931882b000,0x1000,0x1) 55962 gettyRET mprotect 0 55962 gettyCALL kbind(0x7f7c1248,24,0x6843e8d8b828be73) 55962 gettyRET kbind 0 55962 gettyCALL mprotect(0x15931882b000,0x1000,0x3) 55962 gettyRET mprotect 0 55962 gettyCALL mprotect(0x15931882b000,0x1000,0x1) 55962 gettyRET mprotect 0 55962 gettyCALL munmap(0x15931882b000,0x1000) 55962 gettyRET munmap 0 55962 gettyCALL 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
Re: Change to init in -current?
Theodore Wynnychenko 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.
Re: Change to init in -current?
You don't say how you updated to current. If you updated without a snapshot, it is possible you got caught up in a strange malloc change. it is also possible that some unveil / pledge things have broken your strange usage case, for instance maybe "lo" doesn't work anymore due to changes. You can try to insert ktrace -di at a higher level to determine the failure condition. > I just updated to -current. It had been about 2-3 months since I last > updated. > I have been doing so since (about) 5.9 or so. > > Anyway, way back then, I wanted to be able to login on a local serial terminal > without entering a password (yes, I know that there may be disagreement about > the wisdom of this, but, it's what I wanted). > > 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. > > Anyway, this has worked without an issue until today. > > After the update to current, I cannot login on the serial console. This is > true > regardless of whether I use the "specific name" or any other user name on the > system. Basically, after entering any user name at the login prompt, there > is a > delay, and then the login prompt reappears (it appears getty just restarts). > > If I return /etc/ttys to a "default" entry (with the "lo:" option removed, so > that the default /usr/bin/login is run), I can login with any username on the > system, using a password. > > I have checked the man pages for ttys, getty, gettytab, init, ksh, and login, > and can't find anything that has changed. > > I am wondering if something has changed, and, if so, what that may be? > > Thanks > Ted > >
