launch xterm as regular user outputs "open ttydev: Permission denied"

lucasyata · 2021-12-01 20:26:52

The apparent problem was that pacman had a couple of deprecated master keys. So a bunch of programs could not be updated but others did, so there apparently there was some kind of incompatibilities.
I SOMEHOW pass this by the first time.

So when i realized it i refresh the keys:

doas pacman-key --refresh-keys

And just in case:

doas pacman-key --populate archlinux

PD: 'doas' executes provided command as root, just like 'sudo'. So if you have configured sudo use it instead of doas.
Or you can just execute them in a root shell

In case you came here due to the same problem and this is not the root of your problem...
But the mid-part of your problem is that the permissions of /dev/tty are wrong and it restores it's permissions automatically you might be interested in what i came up with to temporally avoid that problem. It was a temporal "solution" but it was helpful for me until find the definitive solution.
It was to append:

sudo chmod 666 && xterm &
# or / and ...
while true ; do sleep 1 && sudo chmod 666 /dev/tty ; done

# ... depending of the case. 
# The option number one dosen't execute a constant loop
# The second option allows to whatever program to call xterm out of the box
# but sometimes during a tiny period of time /dev/null keeps it's original permissions
# between some itinerations.

To my ~/.bashrc (you could also append it to /etc/profile as well)

Special thanks to...
* Seth
* Head_on_a_stick
* loqs

...for your time, support and deication.
You're amazing guys!

If i'd know how to close the thread i'd do.
___________________________________________________________________________

Hello

This is the first time i installed arch and i'm so happy with it.
Anyways it seems like i'm terrible following the instalation guide because it took me 3 days to finish it and solve the problems that i got and when i finally did it my arch install got a large bunch of errors.
I had to start somewhere i guess XD

The case is that one of those errors is that when i try to launch xterm as a regular user it outputs "open ttydev: Permission denied".
If i go to a tty, login, and then launch startx "/usr/bin/xterm" xterm starts but doesn't work, i can write whatever but execute nothing.
Something that maybe is worth to say is that when i pass parameters to "startx" for sample "xterm" it displays a lot of errors relating with graphic drivers, so it doesn't work, but if i put the full path to the executable at least it starts(even if the program it self is not working right).

If i launch it as root it got no problem.
I don't know how to solve it or what could be the root of the problem.

Also i googled it and i found that the problem could be a miss write in the inittab.
File that i don't found in my instalation(i executed "sudo ls --recursive / | grep -F initab" and no literal output called initab)

Or a udev problem, i don't have any idea about this.
_____________________________

The permissions of /dev/tty file are:

Owner: root
Access: read and write

Group: tty
Access: no read, write

Others / Access: none

Allow executing file as a program: no
_____________________________

* I put my user in and out of tty group. No difference.
* I tried to make my regular user the owner of /dev/tty (i was really frustrated), when i did, the file automatically restored the old permissions, so it again belonged to the original owner, root. The same case with the other permissions.

I read:
Arch wiki entries for: xterm, x server, udev.

Thanks for your time
_____________________________

If there's an entry in the forum that has the solution for my problem i apologize, it's my first interaction with the wiki and i don't understand how to use the search function. Sorry

Aslo, for the unclear root of the problem i don't know if this post is in the right session.

PD: If there's problems with my grammar i also apologize for that, english is not my first language.

Last edited by lucasyata (2022-01-03 01:42:21)

Head_on_a_Stick · 2021-12-01 21:05:07

lucasyata wrote:

when i try to launch xterm as a regular user it outputs "open ttydev: Permission denied"

How are you trying to launch xterm, exactly? Where do you see that error?

lucasyata wrote:

If i go to a tty, login, and then launch startx "/usr/bin/xterm" xterm starts but doesn't work, i can write whatever but execute nothing.

That is the expected behaviour. What happens if you (re)move ~/.xinitrc and run 'startx' with no arguments?

lucasyata wrote:

Also i googled it and i found that the problem could be a miss write in the inittab.
File that i don't found in my instalation(i executed "sudo ls --recursive / | grep -F initab" and no literal output called initab)

Arch hasn't used /etc/inittab since the introduction of systemd.

lucasyata wrote:

If i launch it as root

Don't do that.

seth · 2021-12-01 21:50:05

https://wiki.archlinux.org/title/Xinit#xserverrc
And also please post your xinitrc.

The case is that one of those errors is that when i try to launch xterm as a regular user it outputs "open ttydev: Permission denied".

Launch from where?

when i pass parameters to "startx" for sample "xterm" it displays a lot of errors relating with graphic drivers, so it doesn't work, but if i put the full path to the executable at least it starts

The connection makes no sense whatsoever. Does

echo $PATH

include /usr/bin ?

lucasyata · 2021-12-04 22:41:46

First of all, i really, really apologize for the delay.

Head_on_a_Stick wrote:

How are you trying to launch xterm, exactly? Where do you see that error?

I try to launch it from another xterm, started as root and logged into my user. The first xterm can be started from an xserver started as root as well or from gnome using a keyboard shortcut to launch it as root.
So i see the output on the the xterm from i'm calling another one.

Head_on_a_Stick wrote:

That is the expected behaviour. What happens if you (re)move ~/.xinitrc and run 'startx' with no arguments?

There's no ~/.xinit , i'm searching about it

Head_on_a_Stick wrote:

Arch hasn't used /etc/inittab since the introduction of systemd.

Ohhhh, makes sense.

lucasyata wrote:

If i launch it as root

Head_on_a_Stick wrote:

Don't do that.

I usually launch xterm as root and then log into my normal user, anyways what would be the problem if i use xterm as root?(if i'm careful of course)

Last edited by lucasyata (2021-12-04 23:06:08)

lucasyata · 2021-12-04 22:56:36

seth wrote:

And also please post your xinitrc.

I'm searching about why i don't have it(~/.xinitrc).

seth wrote:

Launch from where?

From a xterm started as root but logged into my regular user.
That xterm can be launched in gnome or in a xserver started as root.
Just in case i start xserver from my user this way:

startx /usr/bin/sudo /usr/bin/xterm

seth wrote:

The connection makes no sense whatsoever. Does
echo $PATH
include /usr/bin ?

Yeah it does

/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

I apologize for the delay....

Last edited by lucasyata (2021-12-04 23:01:05)

Head_on_a_Stick · 2021-12-04 23:12:24

lucasyata wrote:

I launch it two ways: from a xserver(started as root and logged in my user) or launching xterm as root, logging into my user and then just typing "xterm".

Why are you starting "xserver" [sic] as root? That's a really stupid thing to do.

And anyway what does "started as root and logged in my user" actually mean? What are the exact commands you used? How do you launch xterm as root? How do you log in to your user? Please provide as much detail as possible and be sure to post actual commands rather than vague descriptions.

lucasyata wrote:

There's no ~/.xinit

(I'm presuming you mean "~/.xinitrc".) So what happens if you log in to a console (TTY) screen as your normal user and run 'startx' (just by itself, no arguments or options) from there?

lucasyata wrote:

what would be the problem if i use xterm as root?

https://en.wikipedia.org/wiki/Principle … _privilege

If you want a root shell use 'sudo -i' or 'su -'. That way only the shell runs with elevated privileges rather than an entire graphical application.

jasonwryan · 2021-12-04 23:13:07

lucasyata wrote:

seth wrote:
And also please post your xinitrc.
I'm searching about why i don't have it(~/.xinitrc).
seth wrote:
Launch from where?
From a xterm started as root but logged into my regular user.
That xterm can be launched in gnome or in a xserver started as root.
Just in case i start xserver from my user this way:
startx /usr/bin/sudo /usr/bin/xterm

None of this sounds remotely like anything documented in the wiki. What makes you think this is how you initialize a graphical environment?

lucasyata · 2021-12-05 01:07:32

Why are you starting "xserver" [sic] as root? That's a really stupid thing to do.

To freely start graphical aplications such as lutris, epiphany, etc i need to start the x server AND in it have access to a terminal.
If i try to start X (without arguments) with my normal user it doesn't work and xterm doesn't works neither.

And anyway what does "started as root and logged in my user" actually mean? What are the exact commands you used? How do you launch xterm as root? How do you log in to your user? Please provide as much detail as possible and be sure to post actual commands rather than vague descriptions.

Ok, sorry, from now on i'll try to be more specific :)
I reallized that i wrote "started as root" instead of "started by root", and just in case with it i mean

sudo xterm

or to start xterm while logged into root:

[myuser@mypc ~]$ su 
[root@mypc previousdir]# xterm

(I'm presuming you mean "~/.xinitrc".) So what happens if you log in to a console (TTY) screen as your normal user and run 'startx' (just by itself, no arguments or options) from there?

Yeah, i meant ~/.xinitrc, my bad.
About what happens...

[myuser@mypc homedir]$ startx

X.Org X Server 1.20.13
X Protocol Version 11, Revision 0
Build Operating System: Linux Archlinux
Current Operating System: Linux SF20PA2 5.14.2-arch1-2 #1 SMP PREEMPT Thu, 09 Sep 2021 09:42:35 +0000 x86_64
Kernel command line: initrd=\intel-ucode.img initrd=\initramfs-linux.img root="LABEL=Arch-root" acpi_backlight=vendor
Build Date: 04 August 2021  08:13:54AM
 
Current version of pixman: 0.40.0
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/home/sgh/.local/share/xorg/Xorg.2.log", Time: Sat Dec  4 21:49:43 2021
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Could not resolve keysym XF86BrightnessAuto
> Warning:          Could not resolve keysym XF86DisplayOff
> Warning:          Could not resolve keysym XF86Info
> Warning:          Could not resolve keysym XF86AspectRatio
> Warning:          Could not resolve keysym XF86DVD
> Warning:          Could not resolve keysym XF86Audio
> Warning:          Could not resolve keysym XF86ChannelUp
> Warning:          Could not resolve keysym XF86ChannelDown
> Warning:          Could not resolve keysym XF86Break
> Warning:          Could not resolve keysym XF86VideoPhone
> Warning:          Could not resolve keysym XF86ZoomReset
> Warning:          Could not resolve keysym XF86Editor
> Warning:          Could not resolve keysym XF86GraphicsEditor
> Warning:          Could not resolve keysym XF86Presentation
> Warning:          Could not resolve keysym XF86Database
> Warning:          Could not resolve keysym XF86Voicemail
> Warning:          Could not resolve keysym XF86Addressbook
> Warning:          Could not resolve keysym XF86DisplayToggle
> Warning:          Could not resolve keysym XF86SpellCheck
> Warning:          Could not resolve keysym XF86ContextMenu
> Warning:          Could not resolve keysym XF86MediaRepeat
> Warning:          Could not resolve keysym XF8610ChannelsUp
> Warning:          Could not resolve keysym XF8610ChannelsDown
> Warning:          Could not resolve keysym XF86Images
> Warning:          Could not resolve keysym XF86NotificationCenter
> Warning:          Could not resolve keysym XF86PickupPhone
> Warning:          Could not resolve keysym XF86HangupPhone
> Warning:          Could not resolve keysym XF86Fn
> Warning:          Could not resolve keysym XF86Fn_Esc
> Warning:          Could not resolve keysym XF86FnRightShift
> Warning:          Could not resolve keysym XF86Numeric0
> Warning:          Could not resolve keysym XF86Numeric1
> Warning:          Could not resolve keysym XF86Numeric2
> Warning:          Could not resolve keysym XF86Numeric3
> Warning:          Could not resolve keysym XF86Numeric4
> Warning:          Could not resolve keysym XF86Numeric5
> Warning:          Could not resolve keysym XF86Numeric6
> Warning:          Could not resolve keysym XF86Numeric7
> Warning:          Could not resolve keysym XF86Numeric8
> Warning:          Could not resolve keysym XF86Numeric9
> Warning:          Could not resolve keysym XF86NumericStar
> Warning:          Could not resolve keysym XF86NumericPound
> Warning:          Could not resolve keysym XF86NumericA
> Warning:          Could not resolve keysym XF86NumericB
> Warning:          Could not resolve keysym XF86NumericC
> Warning:          Could not resolve keysym XF86NumericD
> Warning:          Could not resolve keysym XF86CameraFocus
> Warning:          Could not resolve keysym XF86WPSButton
> Warning:          Could not resolve keysym XF86CameraZoomIn
> Warning:          Could not resolve keysym XF86CameraZoomOut
> Warning:          Could not resolve keysym XF86CameraUp
> Warning:          Could not resolve keysym XF86CameraDown
> Warning:          Could not resolve keysym XF86CameraLeft
> Warning:          Could not resolve keysym XF86CameraRight
> Warning:          Could not resolve keysym XF86AttendantOn
> Warning:          Could not resolve keysym XF86AttendantOff
> Warning:          Could not resolve keysym XF86AttendantToggle
> Warning:          Could not resolve keysym XF86LightsToggle
> Warning:          Could not resolve keysym XF86ALSToggle
> Warning:          Could not resolve keysym XF86Buttonconfig
> Warning:          Could not resolve keysym XF86Taskmanager
> Warning:          Could not resolve keysym XF86Journal
> Warning:          Could not resolve keysym XF86ControlPanel
> Warning:          Could not resolve keysym XF86AppSelect
> Warning:          Could not resolve keysym XF86Screensaver
> Warning:          Could not resolve keysym XF86VoiceCommand
> Warning:          Could not resolve keysym XF86Assistant
> Warning:          Could not resolve keysym XF86BrightnessMin
> Warning:          Could not resolve keysym XF86BrightnessMax
> Warning:          Could not resolve keysym XF86KbdInputAssistPrev
> Warning:          Could not resolve keysym XF86KbdInputAssistNext
> Warning:          Could not resolve keysym XF86KbdInputAssistPrevgroup
> Warning:          Could not resolve keysym XF86KbdInputAssistNextgroup
> Warning:          Could not resolve keysym XF86KbdInputAssistAccept
> Warning:          Could not resolve keysym XF86KbdInputAssistCancel
> Warning:          Could not resolve keysym XF86RightUp
> Warning:          Could not resolve keysym XF86RightDown
> Warning:          Could not resolve keysym XF86LeftUp
> Warning:          Could not resolve keysym XF86LeftDown
> Warning:          Could not resolve keysym XF86RootMenu
> Warning:          Could not resolve keysym XF86MediaTopMenu
> Warning:          Could not resolve keysym XF86Numeric11
> Warning:          Could not resolve keysym XF86Numeric12
> Warning:          Could not resolve keysym XF86AudioDesc
> Warning:          Could not resolve keysym XF863DMode
> Warning:          Could not resolve keysym XF86NextFavorite
> Warning:          Could not resolve keysym XF86StopRecord
> Warning:          Could not resolve keysym XF86PauseRecord
> Warning:          Could not resolve keysym XF86VOD
> Warning:          Could not resolve keysym XF86Unmute
> Warning:          Could not resolve keysym XF86FastReverse
> Warning:          Could not resolve keysym XF86SlowReverse
> Warning:          Could not resolve keysym XF86Data
> Warning:          Could not resolve keysym XF86OnScreenKeyboard
> Warning:          Could not resolve keysym XF86PrivacyScreenToggle
> Warning:          Could not resolve keysym XF86SelectiveScreenshot
> Warning:          Could not resolve keysym XF86Macro1
> Warning:          Could not resolve keysym XF86Macro2
> Warning:          Could not resolve keysym XF86Macro3
> Warning:          Could not resolve keysym XF86Macro4
> Warning:          Could not resolve keysym XF86Macro5
> Warning:          Could not resolve keysym XF86Macro6
> Warning:          Could not resolve keysym XF86Macro7
> Warning:          Could not resolve keysym XF86Macro8
> Warning:          Could not resolve keysym XF86Macro9
> Warning:          Could not resolve keysym XF86Macro10
> Warning:          Could not resolve keysym XF86Macro11
> Warning:          Could not resolve keysym XF86Macro12
> Warning:          Could not resolve keysym XF86Macro13
> Warning:          Could not resolve keysym XF86Macro14
> Warning:          Could not resolve keysym XF86Macro15
> Warning:          Could not resolve keysym XF86Macro16
> Warning:          Could not resolve keysym XF86Macro17
> Warning:          Could not resolve keysym XF86Macro18
> Warning:          Could not resolve keysym XF86Macro19
> Warning:          Could not resolve keysym XF86Macro20
> Warning:          Could not resolve keysym XF86Macro21
> Warning:          Could not resolve keysym XF86Macro22
> Warning:          Could not resolve keysym XF86Macro23
> Warning:          Could not resolve keysym XF86Macro24
> Warning:          Could not resolve keysym XF86Macro25
> Warning:          Could not resolve keysym XF86Macro26
> Warning:          Could not resolve keysym XF86Macro27
> Warning:          Could not resolve keysym XF86Macro28
> Warning:          Could not resolve keysym XF86Macro29
> Warning:          Could not resolve keysym XF86Macro30
> Warning:          Could not resolve keysym XF86MacroRecordStart
> Warning:          Could not resolve keysym XF86MacroRecordStop
> Warning:          Could not resolve keysym XF86MacroPresetCycle
> Warning:          Could not resolve keysym XF86MacroPreset1
> Warning:          Could not resolve keysym XF86MacroPreset2
> Warning:          Could not resolve keysym XF86MacroPreset3
> Warning:          Could not resolve keysym XF86KbdLcdMenu1
> Warning:          Could not resolve keysym XF86KbdLcdMenu2
> Warning:          Could not resolve keysym XF86KbdLcdMenu3
> Warning:          Could not resolve keysym XF86KbdLcdMenu4
> Warning:          Could not resolve keysym XF86KbdLcdMenu5
Errors from xkbcomp are not fatal to the X server
Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
dbus-update-activation-environment: error: unable to connect to D-Bus: Using X11 for dbus-daemon autolaunch was disabled at compile time, set your DBUS_SESSION_BUS_ADDRESS instead
open ttydev: Permission denied
open ttydev: Permission denied
xinit: connection to X server lost

waiting for X server to shut down XIO:  fatal IO error 0 (Success) on X server ":2"
      after 770 requests (770 known processed) with 0 events remaining.
(II) Server terminated successfully (0). Closing log file.

My interpretation about it.

It throws a large bunch of warnings about that xserver couldn't resolve keysym's that starts with XF86, i suppose that it can't find them
That it couldn't connect to d-bus session
And the same thing again
```
open ttydev: Permission denied
```
i guess this error happens because it tries to launch xterm

If you want a root shell use 'sudo -i' or 'su -'. That way only the shell runs with elevated privileges rather than an entire graphical application.

I know, but i use xterm on a x server because it's more easy to manage it that way, to avoid getting out and in of it all the time. If you meant to this.

Last edited by lucasyata (2021-12-05 01:19:06)

lucasyata · 2021-12-05 01:32:34

What makes you think this is how you initialize a graphical environment?

What do you mean exacly?

jasonwryan · 2021-12-05 02:08:37

lucasyata wrote:

What makes you think this is how you initialize a graphical environment?
What do you mean exacly?

I mean where did you read instructions that suggest you do this? It's nowhere documented on the Arch wiki.

seth · 2021-12-05 07:44:42

dbus-update-activation-environment: error: unable to connect to D-Bus: Using X11 for dbus-daemon autolaunch was disabled at compile time, set your DBUS_SESSION_BUS_ADDRESS instead

Did you login in as root and then sudo yourself into your regular user?

Please explain *exactly*, step-by-step, how and as what user you log in after the system booted and how and what graphical session you start.

Also please understand that in case you're trying to run "xterm" from the linux console (the DOS-like text-only shell you were supposed to run "startx" from): that's not gonna work, because there's no display server.

lucasyata · 2021-12-05 14:36:19

Did you login in as root and then sudo yourself into your regular user?
Please explain *exactly*, step-by-step, how and as what user you log in after the system booted and how and what graphical session you start.

Alright...
I will literally copy and paste all what i see and write, so i cannot be more specific.
As i said i try to launch xterm from twm or from gnome, so i'll show both.

First from twm:

(system boots up)

Arch Linux 5.14.2-arch1-2 (tty1)

SF20PA2 login: sgh
Password:

_________________________________________________

loged successfuly, welcome to Arch Linux :)

_________________________________________________

Last login: Sun Dec  5 09:45:31 on tty1
[sgh@SF20PA2 ~]$ sudo startx


X.Org X Server 1.20.13
X Protocol Version 11, Revision 0
Build Operating System: Linux Archlinux
Current Operating System: Linux SF20PA2 5.14.2-arch1-2 #1 SMP PREEMPT Thu, 09 Sep 2021 09:42:35  +0000 x86_64
Kernel command line: initrd=\intel-ucode.img initrd=\initramfs-linux.img root="LABEL=Arch-root"
Build Date: 04 August 2021  08:13:54AM

Current version of pixman: 0.40.0    
           Before reporting problems, check http://wiki.x.org
           to make sure that you have the latest version.
Markers:  (--) probed, (**) from config file, (==) default settings,
             (++) from command line, (!!) notice, (II) informational,
             (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.1.log", Time: Sun Dec  5 10:34:42 2021
(==) Using system config directory "/usr/share/X11/xorg.conf.d"

Then in front of me are: 3 xterms and xclock.
In whatever xterm i execute:

[root@SF20PA2 sgh]# su sgh
[sgh@SF20PA2 ~]$ sudo xhost +
access control disabled, clients can connect from any host
[sgh@SF20PA2 ~]$ xterm
open ttydev: Permission denied 
[sgh@SF20PA2 ~]$

From gnome:

(system boots up)

Arch Linux 5.14.2-arch1-2 (tty1)

SF20PA2 login: sgh
Password:

_________________________________________________

loged successfuly, welcome to Arch Linux :)

_________________________________________________

Last login: Sun Dec  5 11:23:22 on tty1
[sgh@SF20PA2 ~]$ gnome # "gnome" is just an sh file located in /usr/bin/gnome that only executes "sudo systemctl start gdm.service", it basically works as an alias.

So it starts gnome, i autoatically log in, so the first thing i see is my desktop. In it i use the keyboard shortcut "ctl+super+t" that executes the command "sudo xterm", so an xterm appears and in it....

[root@SF20PA2 sgh]# su sgh
[sgh@SF20PA2 ~]$ xterm
open ttydev: Permission denied
[sgh@SF20PA2 ~]$

I copied all this by hand, i reviewed it several times to make sure it does have as least errors as possible.

Also please understand that in case you're trying to run "xterm" from the linux console (the DOS-like text-only shell you were supposed to run "startx" from): that's not gonna work, because there's no display server.

Yeah, to launch an graphical program you need a graphical environment, that's the point of startx right?
Why the mention?

Also, about ~/.xinitrc
I searched about it, and when it does not exists the default file(/etc/X11/xinit/xinitrc) is used by default.
And the default ~/.xinitrc is a copy of that file, so that it does not exist should not make any difference, but just in case i executed

[sgh@SF20PA2 ~]$ startx /etc/X11/xinit/xinitrc

I tried it 5 times, the fouth time it started xterm, twm and xclock. xterm was not working anyways but at least that time xserver didn't ended inmediately after executing the startx command.
Just maybe this could be useful.

Last edited by lucasyata (2021-12-05 14:56:18)

seth · 2021-12-05 15:10:42

[sgh@SF20PA2 ~]$ sudo startx

Don't do that. Also you probably now have an inaccessible ~/.Xauthority ?
Don't run startx (or any display server) as root and *certainly* not using sudo.

stat ~sgh/.Xauthority
xauth info
xauth list

Fix the file permissions, then see the wiki entry about the xserver configuration I posted in #3

Why the mention?

Because I was sunder the impression that you might have tried to run xterm directly out of the console.

lucasyata · 2021-12-05 22:57:56

seth wrote:

Don't run startx (or any display server) as root and *certainly* not using sudo.

Until find a solution for this problem i don't promiss nothing. By the way what's the difference between executing something in a root shell and executing it with sudo?

Fix the file permissions, then see the wiki entry about the xserver configuration I posted in #3

The permissions seems to be ok.
~/.Xauthority is owned by my user, i can write on it with no problems, and also i can launch programs like winecfg, nautilus and epiphany for sample without errors.
Just in case...

[sgh@SF20PA2 ~]$ xauth info
Authority file:           /home/sgh/.Xauthority
File new:                 no
File locked:             no
Number of entries:   0
Changes honored:   yes
Changes made:       no
Current input:          (argv):1
[sgh@SF20PA2 ~]$ stat ./.Xauthority
  File: ./.Xauthority
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: b303h/45827d	Inode: 6011        Links: 1
Access: (0600/-rw-------)  Uid: ( 1000/     sgh)   Gid: ( 1000/     sgh)
Access: 2021-12-05 18:41:17.047208219 -0300
Modify: 2021-12-05 18:40:25.277204661 -0300
Change: 2021-12-05 18:40:25.277204661 -0300
 Birth: 2021-12-05 18:40:25.277204661 -0300
[sgh@SF20PA2 ~]$ xauth list
[sgh@SF20PA2 ~]$

The problem seems to be launching xterm not xserver.

lucasyata · 2021-12-05 23:04:11

There's some way to make xterm verbose?
I've searched in the arch wiki entry about xterm, but nothing about it's internal start process.

The startx log says that there's a xorg wiki, i'll search about how xterm starts in it.
I don't know where else to look for the root of the problem guys

lucasyata · 2021-12-05 23:44:41

Ok, sooo.

I can launch other graphical programs except of xterm using my regular user.
Xterm starts without problems as root.
All non privileged users got the error "open ttydev: Permission denied"
The properties of /dev/tty seem to not be the problem (owner root: read and write / group tty: no read, write / others: none)
The output error of xterm is 0

So, as i can launch other graphical programs except of xterm, i think that the configuration of x server it's not the problem.
As the error doesn't occurs when i'm logged as root, i think it could be something related to "user-specific" configurations or permission issues, not internal xterm miss working.
But due that other regular users(even just created ones) have the same problem as well it probably relates to wrong permissions of some file.

I'll search about internal working of xterm, maybe i'll find something useful.
The files that it uses, some env variables maybe, idk.

What a mess

Last edited by lucasyata (2021-12-06 00:00:05)

2ManyDogs · 2021-12-05 23:48:51

lucsyata, please stop bumping the the thread. If you have something to add and no one has replied, use the Edit link to add to your existing post.

Moving to Newbie Corner.

seth · 2021-12-06 08:46:43

xterm tries to open /dev/tty

% strace xterm 2>&1 | grep tty
openat(AT_FDCWD, "/dev/tty", O_RDWR)    = 4

What works because

% getfacl dev/tty
# file: dev/tty
# owner: root
# group: tty
user::rw-
group::rw-
other::rw-

Because

% grep tty /usr/lib/udev/rules.d/50-udev-default.rules
…
SUBSYSTEM=="tty", KERNEL=="tty", GROUP="tty", MODE="0666"
…

Whereas the permissions of numbered ttys are limited

% grep tty /usr/lib/udev/rules.d/50-udev-default.rules
…
SUBSYSTEM=="tty", KERNEL=="tty[0-9]*", GROUP="tty", MODE="0620"
…

and system assigns the owner to the user active on that tty.

Until find a solution for this problem i don't promiss nothing

I'm pretty sure stopping your wacko approach to log into a graphical root session and then dropping privilegues from there, let alone while dropping all environment w/ sudo, is gonna be the solution of this.

lucasyata · 2021-12-06 15:22:16

seth wrote:

What works because

% getfacl dev/tty
# file: dev/tty
# owner: root
# group: tty
user::rw-
group::rw-
other::rw-

This is the key!

I bypassed this becuase i changed the permissions, checked to launched xterm again and the error came out anyways.
I tried again but this time i reallized that...

[root@SF20PA2 ~]# ls -l /dev/tty && chmod 666 /dev/tty && ls -l /dev/tty && sleep 4 && ls -l /dev/tty
crw--w---- 1 root tty 5, 0 Dec  6 11:15 /dev/tty
crw-rw-rw-1 root tty 5, 0 Dec  6 11:15 /dev/tty
crw--w---- 1 root tty 5, 0 Dec  6 11:15 /dev/tty
[root@SF20PA2 ~]#

The permissions automatically reset after a few seconds.
I tested if it was a miss understanding or something, so i execed in a tty:

[root@SF20PA2 ~]# while true ; do chown 666 /dev/tty ; done

and tried to execute xterm as regular user, it runs, no problem.

lucasyata wrote:

Until find a solution for this problem i don't promiss nothing

seth wrote:

I'm pretty sure stopping your wacko approach to log into a graphical root session and then dropping privilegues from there, let alone while dropping all environment w/ sudo, is gonna be the solution of this.

In the last post i said that i had no problem with xserver.
In that moment i didn't realized that i just could start x server as normal and launch xterm as root, fool i.

In any case there's still the problem that permissions of /dev/tty resets automatically, should i start a new thread for that problem and give this tread as resolved or keep on this?

Last edited by lucasyata (2021-12-06 15:39:58)

ewaller · 2021-12-06 15:24:29

Keep it here. please

loqs · 2021-12-06 20:58:41

Why would xterm be using /dev/tty instead of /dev/ptmx / dev/pts/# ?

seth · 2021-12-06 21:51:23

https://github.com/ThomasDickey/xterm-s … in.c#L3768
git blame has it at https://github.com/ThomasDickey/xterm-s … 8040b336ea - from 2005…

loqs · 2021-12-06 22:31:08

I think it is this use of /dev/tty which is failing instead
https://github.com/ThomasDickey/xterm-s … in.c#L4230

Which matches with you assessment the session is broken.

seth · 2021-12-06 22:51:19

And especially since https://github.com/ThomasDickey/xterm-s … in.c#L4245 fits the error in the subject of this thread.

But I actually only get

% strace xterm 2>&1 | grep -C10 tty
newfstatat(4, "", {st_mode=S_IFREG|0644, st_size=1204, ...}, AT_EMPTY_PATH) = 0
read(4, "Xcur\20\0\0\0\0\0\1\0\1\0\0\0\2\0\375\377 \0\0\0\34\0\0\0$\0\0\0"..., 4096) = 1204
lseek(4, 0, SEEK_SET)                   = 0
read(4, "Xcur\20\0\0\0\0\0\1\0\1\0\0\0\2\0\375\377 \0\0\0\34\0\0\0$\0\0\0"..., 4096) = 1204
close(4)                                = 0
rt_sigaction(SIGTTOU, {sa_handler=SIG_IGN, sa_mask=[TTOU], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f6ac3f5dda0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigaction(SIGALRM, {sa_handler=0x55c8d496e5f0, sa_mask=[ALRM], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f6ac3f5dda0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
alarm(2)                                = 0
openat(AT_FDCWD, "/dev/tty", O_RDWR)    = 4
alarm(0)                                = 2
rt_sigaction(SIGALRM, {sa_handler=SIG_DFL, sa_mask=[ALRM], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f6ac3f5dda0}, {sa_handler=0x55c8d496e5f0, sa_mask=[ALRM], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f6ac3f5dda0}, 8) = 0
ioctl(4, TCGETS, {B38400 opost isig icanon echo ...}) = 0
close(4)                                = 0
openat(AT_FDCWD, "/dev/ptmx", O_RDWR)   = 4
ioctl(4, TIOCGPTN, [1])                 = 0
…

What matches the other position - *shrug*

lucasyata · 2021-12-07 00:51:29

And especially since https://github.com/ThomasDickey/xterm-s … in.c#L4245 fits the error in the subject of this thread.

I got lost 4 replies ago ._.

I did a work around to avoid the error.
It is just add a line to my ~/.bashrc:

if [[ "$USER" != root ]] ; then while true ; do sudo chmod 666 /dev/tty & sleep 2 ; done ; fi &

As the .bashrc file of all users are symbolic links to /home/sgh/.bashrc(i added that line to this file) all non root users will execute that line and the error "Permission denied" will not ocur.
I now it's lazy as freak, maybe there's a more efficient way to do it, but for the moment at least it works.

Now i should put all this in the post and mark it as solved?
Technically the problem in the title of the post is ""solved"", even when it's a temporal and non optmal solution.
I think that it would be more adecuated to make another post about why the permissions of /dev/tty resets after a few seconds.

what do you think about it?

Last edited by lucasyata (2021-12-07 01:01:34)

Arch Linux

#1 2021-12-01 20:26:52

launch xterm as regular user outputs "open ttydev: Permission denied"

#2 2021-12-01 21:05:07

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#3 2021-12-01 21:50:05

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#4 2021-12-04 22:41:46

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#5 2021-12-04 22:56:36

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#6 2021-12-04 23:12:24

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#7 2021-12-04 23:13:07

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#8 2021-12-05 01:07:32

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#9 2021-12-05 01:32:34

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#10 2021-12-05 02:08:37

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#11 2021-12-05 07:44:42

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#12 2021-12-05 14:36:19

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#13 2021-12-05 15:10:42

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#14 2021-12-05 22:57:56

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#15 2021-12-05 23:04:11

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#16 2021-12-05 23:44:41

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#17 2021-12-05 23:48:51

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#18 2021-12-06 08:46:43

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#19 2021-12-06 15:22:16

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#20 2021-12-06 15:24:29

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#21 2021-12-06 20:58:41

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#22 2021-12-06 21:51:23

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#23 2021-12-06 22:31:08

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#24 2021-12-06 22:51:19

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

#25 2021-12-07 00:51:29

Re: launch xterm as regular user outputs "open ttydev: Permission denied"

Board footer