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

loqs · 2021-12-07 04:31:47

All users can sudo any command without password?

The core issue is su / su --login / sudo / sudo --login do not set up a session. login and display managers do setup a session. The sessions owner has access to files through uaccess meaning when you fix your session you can stop doing these work arounds.

seth · 2021-12-07 07:51:27

lucasyata wrote:

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 &
…
what do you think about it?

https://www.youtube.com/watch?v=XPpJcnEoijU

lucasyata · 2021-12-07 15:09:13

loqs wrote:

All users can sudo any command without password?

Yes. I've set up sudo to not ask for password to members of the wheel group.

/etc/sudoers
%wheel ALL=(ALL) NOPASSWD: ALL

Could be this a problem?

su / su --login / sudo / sudo --login do not set up a session.

.
What do you mean exactly with "set up a session"?

The sessions owner has access to files through uaccess

What has to do "su / sudo / login" with uaccess?

Last edited by lucasyata (2021-12-07 16:25:12)

seth · 2021-12-07 15:31:45

Could be this a problem?

Depends on who gets access to the system.

What do you mean exactly with "set up a session"?

When you login properly as your user (sgh) , logind will transfer control over teh active the terminal to that user.
With your approach that doesn't happen, or rather control is offered to the root (which has it anyway) and therefore you run into access issues (in this case w/ xterm and /dev/tty, but there's more trouble ahead)
This is just on top of all the security issues you run into when lauching graphical sessions as root (because they imply maaaaany LOCs), so stop that. Login as your user and lever root access whenever you need it. Not the other way round.

lucasyata · 2021-12-07 16:22:09

Now the only user in the wheel group is my regular user "sgh". Do you meant that?

This is just on top of all the security issues you run into when lauching graphical sessions as root

Ok, but for the moment when i need an xterm i run "chmod 666 /dev/tty && xterm &" and that term works, so starting X as root has no sense. I used to did that becuse i did't know other way to access to a terminal in a graphical session. Now that i know that running graphical sessions as root can lead to headaches i'll will not do it anymore.

When you login properly as your user (sgh) , logind will transfer control over teh active the terminal to that user.
With your approach that doesn't happen

But i log in on a tty, the control should'nt transfer to my user?
And with "control transfer" do you mean that permissions of the file changes? Because if i manually change them there's no any kind of error.

BTW:

seth wrote:

https://www.youtube.com/watch?v=XPpJcnEoijU

XD

Last edited by lucasyata (2021-12-07 16:24:27)

seth · 2021-12-07 16:56:43

No, I mean whether somebody else than you might be able to login as sgh (eg. via ssh) and gain easy access to a root shell. Unconditional sudo might be convenient, but removes the protection that sudo is meant to gain you.

when i need an xterm i run "chmod 666 /dev/tty && xterm &" and that term works, so starting X as root has no sense

The idea is that if you login properly as sgh and run your graphical session as sgh, you will not have to resort to this Homer-grade "solution".

But i log in on a tty, the control should'nt transfer to my user?

Yes, they should. That's the whole point. Your user gets control over the active terminal where they are logged in (and nothing else)

jasonwryan · 2021-12-07 17:00:33

giphy.gif?cid=ecf05e47g7l9kiocgkkxuukbr8wcxt5zr3a6frympfo0bhtd&rid=giphy.gif&ct=g

lucasyata · 2021-12-07 17:38:53

No, I mean whether somebody else than you might be able to login as sgh (eg. via ssh) and gain easy access to a root shell. Unconditional sudo might be convenient, but removes the protection that sudo is meant to gain you.

I'm the only user of my pc, i get the point but i don't care.

The idea is that if you login properly as sgh and run your graphical session as sgh, you will not have to resort to this Homer-grade "solution".

As i said before, i don't start X as root anymore, if that's would be the only problem then i'd already check this thread as resolved.
If with "login properly" you refer to login on a tty, then i already do that. But the problem is still there.
And if you don't refear to that then what?

As i see it the front-end of the problem is that xterm is unable to access /dev/tty fully, that is due that the default permissions of it are wrong for some reason, if i try to manually change them they something restore them automatically for some reason.

I'm tring to find out why the default permissions of /dev/tty are wrong and what defines them in first place or why when i change them they restore automatically and who does it.
@loqs suggested that it could be somehow my login, i really don't know, i'm looking about it.
Also he mentiond "uaccess" i'm looking for what it is.

Last edited by lucasyata (2021-12-07 17:41:39)

seth · 2021-12-07 17:42:56

From your immediate login (assuming you're running "startx": before doing that) post

(stat /dev/tty; loginctl session-status) | curl -F 'f:1=<-' ix.io

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

(stat /dev/tty; loginctl session-status) | curl -F 'f:1=<-' ix.io

It outputs that -F is badly used and that input field is illegaly formatted.
I don't know what you're tring to do with that command or what "'f:1=<-' ix.io" is sooo...

Did you wrote it right?
Maybe it's grep instead of curl or something?

Last edited by lucasyata (2021-12-07 18:33:52)

seth · 2021-12-07 18:32:37

https://man.archlinux.org/man/core/curl/curl.1.en#F,

So let's get to the obvious question: what system/distro do *actually* you use?

Edit: so apparently did you find the proper manpage…
The command uploads the output of the two enclosed commands into ix.io and no: it's not wrong. The error is on your side.

Last edited by seth (2021-12-07 18:33:59)

lucasyata · 2021-12-07 18:36:40

https://man.archlinux.org/man/core/curl/curl.1.en#F,
So let's get to the obvious question: what system/distro do *actually* you use?

Sorry, i pass it by until the fourth time i read it, i just finished edited my reply, sorry
(and if it was not a joke, i use vanilla arch linux)

seth · 2021-12-07 18:40:09

Redirect the output of those commands into files and upload those, but either way: we want to see that data.

The question about your OS was triggered by the claim that your curl doesn't provide "-F" which rules out most if not all unix systems (no idea about wsl/curl for windows)

lucasyata · 2021-12-07 18:54:24

http://ix.io/3HiB

  File: /dev/tty
  Size: 0         	Blocks: 0          IO Block: 4096   character special file
Device: 5h/5d	Inode: 15          Links: 1     Device type: 5,0
Access: (0620/crw--w----)  Uid: (    0/    root)   Gid: (    5/     tty)
Access: 2021-12-07 15:45:16.370000334 -0300
Modify: 2021-12-07 15:45:16.370000334 -0300
Change: 2021-12-07 15:46:50.603340141 -0300
 Birth: -
8 - sgh (1000)
	   Since: Tue 2021-12-07 15:51:11 -03; 3s ago
	  Leader: 1612 (login)
	    Seat: seat0; vc2
	     TTY: tty2
	 Service: login; type tty; class user
	   State: active
	    Unit: session-8.scope
		  |-1612 "login -- sgh" "" "" "" "" "" "" "" ""
		  |-1682 -bash
		  |-1686 -bash
		  |-1687 -bash
		  |-1688 curl -F "f:1=<-" ix.io
		  `-1690 loginctl session-status

Dec 07 15:51:11 SF20PA2 systemd[1]: Started Session 8 of User sgh.
Dec 07 15:51:11 SF20PA2 login[1612]: LOGIN ON tty2 BY sgh

I quited my tty session, logged again and execed that. It's ok or did you mean to reboot my pc?

ewaller · 2021-12-07 19:01:00

seth wrote:

From your immediate login (assuming you're running "startx": before doing that) post
(stat /dev/tty; loginctl session-status) | curl -F 'f:1=<-' ix.io

Seth, that is genius. I shall do you the compliment of stealing that trick.

seth · 2021-12-07 19:36:36

	    Seat: seat0; vc2
	     TTY: tty2

What is on vc1?

If that doesn't get us anywhere, please post your copy of /usr/lib/udev/rules.d/50-udev-default.rules and

grep -r tty /{usr/lib,etc}/udev/rules.d/

lucasyata · 2021-12-08 02:19:42

seth wrote:

What is on vc1?

I couldn't find what vc stands for, but i suppose that i something like virtual console.
Anyways, if i'm not wrong in that moment i had a x session in the tty 1.

please post your copy of /usr/lib/udev/rules.d/50-udev-default.rules

# do not edit this file, it will be overwritten on update

# run a command on remove events
ACTION=="remove", ENV{REMOVE_CMD}!="", RUN+="$env{REMOVE_CMD}"
ACTION=="remove", GOTO="default_end"

SUBSYSTEM=="virtio-ports", KERNEL=="vport*", ATTR{name}=="?*", SYMLINK+="virtio-ports/$attr{name}"

# select "system RTC" or just use the first one
SUBSYSTEM=="rtc", ATTR{hctosys}=="1", SYMLINK+="rtc"
SUBSYSTEM=="rtc", KERNEL=="rtc0", SYMLINK+="rtc", OPTIONS+="link_priority=-100"

SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", IMPORT{builtin}="usb_id", IMPORT{builtin}="hwdb --subsystem=usb"
ENV{MODALIAS}!="", IMPORT{builtin}="hwdb --subsystem=$env{SUBSYSTEM}"

ACTION!="add", GOTO="default_end"

SUBSYSTEM=="tty", KERNEL=="ptmx", GROUP="tty", MODE="0666"
SUBSYSTEM=="tty", KERNEL=="tty", GROUP="tty", MODE="0666"
SUBSYSTEM=="tty", KERNEL=="tty[0-9]*", GROUP="tty", MODE="0620"
SUBSYSTEM=="tty", KERNEL=="sclp_line[0-9]*", GROUP="tty", MODE="0620"
SUBSYSTEM=="tty", KERNEL=="ttysclp[0-9]*", GROUP="tty", MODE="0620"
SUBSYSTEM=="tty", KERNEL=="3270/tty[0-9]*", GROUP="tty", MODE="0620"
SUBSYSTEM=="vc", KERNEL=="vcs*|vcsa*", GROUP="tty"
KERNEL=="tty[A-Z]*[0-9]|ttymxc[0-9]*|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*", GROUP="uucp"

SUBSYSTEM=="mem", KERNEL=="mem|kmem|port", GROUP="kmem", MODE="0640"

SUBSYSTEM=="input", GROUP="input"
SUBSYSTEM=="input", KERNEL=="js[0-9]*", MODE="0664"

SUBSYSTEM=="video4linux", GROUP="video"
SUBSYSTEM=="graphics", GROUP="video"
SUBSYSTEM=="drm", KERNEL!="renderD*", GROUP="video"
SUBSYSTEM=="dvb", GROUP="video"
SUBSYSTEM=="media", GROUP="video"
SUBSYSTEM=="cec", GROUP="video"

SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="render", MODE="0666"
SUBSYSTEM=="kfd", GROUP="render", MODE="0666"

SUBSYSTEM=="misc", KERNEL=="sgx_enclave", GROUP="sgx", MODE="0660"

# When using static_node= with non-default permissions, also update
# tmpfiles.d/static-nodes-permissions.conf.in to keep permissions synchronized.

SUBSYSTEM=="sound", GROUP="audio", \
  OPTIONS+="static_node=snd/seq", OPTIONS+="static_node=snd/timer"

SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", MODE="0664"

SUBSYSTEM=="firewire", TEST=="units", TEST=="model", \
  IMPORT{builtin}="hwdb 'ieee1394:node:ven$attr{vendor}mo$attr{model}units$attr{units}'"

SUBSYSTEM=="firewire", TEST=="units", TEST!="model", \
  IMPORT{builtin}="hwdb 'ieee1394:node:ven$attr{vendor}units$attr{units}'"

SUBSYSTEM=="firewire", TEST=="units", ENV{IEEE1394_UNIT_FUNCTION_MIDI}=="1", GROUP="audio"
SUBSYSTEM=="firewire", TEST=="units", ENV{IEEE1394_UNIT_FUNCTION_AUDIO}=="1", GROUP="audio"
SUBSYSTEM=="firewire", TEST=="units", ENV{IEEE1394_UNIT_FUNCTION_VIDEO}=="1", GROUP="video"

KERNEL=="parport[0-9]*", GROUP="lp"
SUBSYSTEM=="printer", KERNEL=="lp*", GROUP="lp"
SUBSYSTEM=="ppdev", GROUP="lp"
KERNEL=="lp[0-9]*", GROUP="lp"
KERNEL=="irlpt[0-9]*", GROUP="lp"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", GROUP="lp"

SUBSYSTEM=="block", GROUP="disk"
SUBSYSTEM=="block", KERNEL=="sr[0-9]*", GROUP="optical"
SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="4|5", GROUP="optical"
KERNEL=="sch[0-9]*", GROUP="optical"
KERNEL=="pktcdvd[0-9]*", GROUP="optical"
KERNEL=="pktcdvd", GROUP="optical"

SUBSYSTEM=="scsi_generic|scsi_tape", SUBSYSTEMS=="scsi", ATTRS{type}=="1|8", GROUP="storage"
SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="0", GROUP="disk"
KERNEL=="qft[0-9]*|nqft[0-9]*|zqft[0-9]*|nzqft[0-9]*|rawqft[0-9]*|nrawqft[0-9]*", GROUP="disk"
KERNEL=="loop-control", GROUP="disk", OPTIONS+="static_node=loop-control"
KERNEL=="btrfs-control", GROUP="disk"
KERNEL=="rawctl", GROUP="disk"
SUBSYSTEM=="raw", KERNEL=="raw[0-9]*", GROUP="disk"
SUBSYSTEM=="aoe", GROUP="disk", MODE="0220"
SUBSYSTEM=="aoe", KERNEL=="err", MODE="0440"

KERNEL=="rfkill", MODE="0664"
KERNEL=="tun", MODE="0666", OPTIONS+="static_node=net/tun"

KERNEL=="fuse", MODE="0666", OPTIONS+="static_node=fuse"

# The static_node is required on s390x and ppc (they are using MODULE_ALIAS)
KERNEL=="kvm", GROUP="kvm", MODE="0666", OPTIONS+="static_node=kvm"

KERNEL=="vfio", MODE="0666", OPTIONS+="static_node=vfio/vfio"

KERNEL=="vsock", MODE="0666"
KERNEL=="vhost-vsock", GROUP="kvm", MODE="0666", OPTIONS+="static_node=vhost-vsock"

KERNEL=="vhost-net", GROUP="kvm", MODE="0666", OPTIONS+="static_node=vhost-net"

KERNEL=="udmabuf", GROUP="kvm"

SUBSYSTEM=="ptp", ATTR{clock_name}=="KVM virtual PTP", SYMLINK += "ptp_kvm"

SUBSYSTEM=="ptp", ATTR{clock_name}=="hyperv", SYMLINK += "ptp_hyperv"

SUBSYSTEM=="dmi", ENV{ID_SYSFS_ATTRIBUTE_MODEL}=="", ENV{ID_VENDOR}="$attr{sys_vendor}", ENV{ID_MODEL}="$attr{product_name}"
SUBSYSTEM=="dmi", ENV{ID_SYSFS_ATTRIBUTE_MODEL}=="product_version", ENV{ID_VENDOR}="$attr{sys_vendor}", ENV{ID_MODEL}="$attr{product_version}"

LABEL="default_end"

It seems to be ok, at least tty, i don't know if tty[0-9] should be only writeable to the tty group.

About the output of "grep -r tty /{usr/lib,etc}/udev/rules.d/" i made a little modification, i added the flag -w to grep.

/usr/lib/udev/rules.d/65-libwacom.rules:ENV{ID_BUS}=="tty|pnp", ATTRS{id}=="WACf*", ENV{ID_INPUT}="1", ENV{ID_INPUT_TABLET}="1", GOTO="libwacom_end"
/usr/lib/udev/rules.d/65-libwacom.rules:ENV{ID_BUS}=="tty|pnp", ATTRS{id}=="FUJ*", ENV{ID_INPUT}="1", ENV{ID_INPUT_TABLET}="1", GOTO="libwacom_end"
/usr/lib/udev/rules.d/50-udev-default.rules:SUBSYSTEM=="tty", KERNEL=="ptmx", GROUP="tty", MODE="0666"
/usr/lib/udev/rules.d/50-udev-default.rules:SUBSYSTEM=="tty", KERNEL=="tty", GROUP="tty", MODE="0666"
/usr/lib/udev/rules.d/50-udev-default.rules:SUBSYSTEM=="tty", KERNEL=="tty[0-9]*", GROUP="tty", MODE="0620"
/usr/lib/udev/rules.d/50-udev-default.rules:SUBSYSTEM=="tty", KERNEL=="sclp_line[0-9]*", GROUP="tty", MODE="0620"
/usr/lib/udev/rules.d/50-udev-default.rules:SUBSYSTEM=="tty", KERNEL=="ttysclp[0-9]*", GROUP="tty", MODE="0620"
/usr/lib/udev/rules.d/50-udev-default.rules:SUBSYSTEM=="tty", KERNEL=="3270/tty[0-9]*", GROUP="tty", MODE="0620"
/usr/lib/udev/rules.d/50-udev-default.rules:SUBSYSTEM=="vc", KERNEL=="vcs*|vcsa*", GROUP="tty"
/usr/lib/udev/rules.d/50-udev-default.rules:KERNEL=="tty[A-Z]*[0-9]|ttymxc[0-9]*|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*", GROUP="uucp"
/usr/lib/udev/rules.d/95-upower-wup.rules:SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A80?????", ENV{UPOWER_VENDOR}="Watts Up, Inc.", ENV{UPOWER_PRODUCT}="Watts Up? Pro", ENV{UP_MONITOR_TYPE}="wup"
/usr/lib/udev/rules.d/99-systemd.rules:SUBSYSTEM=="tty", KERNEL=="tty[a-zA-Z]*|hvc*|xvc*|hvsi*|ttysclp*|sclp_line*|3270/tty[0-9]*", TAG+="systemd"
/usr/lib/udev/rules.d/60-serial.rules:SUBSYSTEM!="tty", GOTO="serial_end"
/etc/udev/rules.d/99-arduino-101.rules:SUBSYSTEM=="tty", ENV{ID_REVISION}=="8087", ENV{ID_MODEL_ID}=="0ab6", MODE="0666", ENV{ID_MM_DEVICE_IGNORE}="1", ENV{ID_MM_CANDIDATE}="0"
/etc/udev/rules.d/98-openocd.rules:SUBSYSTEM!="usb|tty|hidraw", GOTO="openocd_rules_end"

(I reorgnized it to be easier to read.)

/usr/lib/udev/rules.d/65-libwacom.rules:
ENV{ID_BUS}=="tty|pnp", ATTRS{id}=="WACf*", ENV{ID_INPUT}="1", ENV{ID_INPUT_TABLET}="1", GOTO="libwacom_end"
ENV{ID_BUS}=="tty|pnp", ATTRS{id}=="FUJ*", ENV{ID_INPUT}="1", ENV{ID_INPUT_TABLET}="1", GOTO="libwacom_end"

/usr/lib/udev/rules.d/50-udev-default.rules:
SUBSYSTEM=="tty", KERNEL=="ptmx", GROUP="tty", MODE="0666"
SUBSYSTEM=="tty", KERNEL=="tty", GROUP="tty", MODE="0666"
SUBSYSTEM=="tty", KERNEL=="tty[0-9]*", GROUP="tty", MODE="0620"
SUBSYSTEM=="tty", KERNEL=="sclp_line[0-9]*", GROUP="tty", MODE="0620"
SUBSYSTEM=="tty", KERNEL=="ttysclp[0-9]*", GROUP="tty", MODE="0620"
SUBSYSTEM=="tty", KERNEL=="3270/tty[0-9]*", GROUP="tty", MODE="0620"
SUBSYSTEM=="vc", KERNEL=="vcs*|vcsa*", GROUP="tty"
KERNEL=="tty[A-Z]*[0-9]|ttymxc[0-9]*|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*", GROUP="uucp"

/usr/lib/udev/rules.d/95-upower-wup.rules:
SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A80?????", ENV{UPOWER_VENDOR}="Watts Up, Inc.", ENV{UPOWER_PRODUCT}="Watts Up? Pro", ENV{UP_MONITOR_TYPE}="wup"

/usr/lib/udev/rules.d/99-systemd.rules:
SUBSYSTEM=="tty", KERNEL=="tty[a-zA-Z]*|hvc*|xvc*|hvsi*|ttysclp*|sclp_line*|3270/tty[0-9]*", TAG+="systemd"

/usr/lib/udev/rules.d/60-serial.rules:
SUBSYSTEM!="tty", GOTO="serial_end"

/etc/udev/rules.d/99-arduino-101.rules:
SUBSYSTEM=="tty", ENV{ID_REVISION}=="8087", ENV{ID_MODEL_ID}=="0ab6", MODE="0666", ENV{ID_MM_DEVICE_IGNORE}="1", ENV{ID_MM_CANDIDATE}="0"

/etc/udev/rules.d/98-openocd.rules:
SUBSYSTEM!="usb|tty|hidraw", GOTO="openocd_rules_end"

Anyways it seems like the only interesting part is "/usr/lib/udev/rules.d/50-udev-default.rules:"

_______________________________

I'm searching about what "[]" and "*" do and how they work in udev rules.
Maybe, just maybe ' SUBSYSTEM=="tty", KERNEL=="tty[0-9]*", GROUP="tty", MODE="0620" ' affects from tty 1 - 9 but also to tty.
Maybe it's a possibility that square braquets could be substituted by literally nothing, and affect /dev/tty too? The permissions of that line matches the permissions of /dev/tty (0620).
Also this line is below the one dedicated to /dev/tty, so if this would be true, then when this line gets executed it will overwrite the default permissions of /dev/tty specificated in the previous line.

I'm fully supposing but maybe it could be a possibility.

Last edited by lucasyata (2021-12-08 03:16:39)

seth · 2021-12-08 07:11:46

Anyways, if i'm not wrong in that moment i had a x session in the tty 1.

I actually meant "right after booting the system, w/o doing anything else" when I said "From your immediate login"
So please provide the output from that very condition, not a secondary login, no "login" via su/sudo/…

I'm searching about what "[]" and "*" do

https://en.wikipedia.org/wiki/Regular_expression - the udev rules are fine. The expression matches also the pure "tty" but there's a stronger and earlier match.

Compare

sudo udevadm test /class/tty/tty
sudo udevadm test /class/tty/tty1

lucasyata · 2021-12-11 19:44:59

I'm back
The output of "(stat /dev/tty; loginctl session-status)" RIGHT AFTER TURN ON my pc is:

  File: /dev/tty
  Size: 0         	Blocks: 0          IO Block: 4096   character special file
Device: 5h/5d	Inode: 15          Links: 1     Device type: 5,0
Access: (0620/crw--w----)  Uid: (    0/    root)   Gid: (    5/     tty)
Access: 2021-12-11 14:19:16.856666966 -0300
Modify: 2021-12-11 14:19:16.856666966 -0300
Change: 2021-12-11 14:19:16.943333638 -0300
 Birth: -
1 - sgh (1000)
	   Since: Sat 2021-12-11 14:19:32 -03; 8s ago
	  Leader: 284 (login)
	    Seat: seat0; vc1
	     TTY: tty1
	 Service: login; type tty; class user
	   State: active
	    Unit: session-1.scope
		  |-284 "login -- sgh" "" "" "" "" "" "" "" ""
		  |-352 -bash
		  |-358 -bash
		  |-359 -bash
		  `-361 loginctl session-status

Dec 11 14:19:32 SF20PA2 login[284]: LOGIN ON tty1 BY sgh
Dec 11 14:19:32 SF20PA2 systemd[1]: Started Session 1 of User sgh.

Nothing new, and /dev/tty permissions are crw--w--- .

That would mean that between udev rule about /dev/tty is loaded(the first time) and i log in something happens that makes the permissions of /dev/tty change right?
I'll read again the wiki entry about arch boot process.

Last edited by lucasyata (2021-12-11 19:48:04)

seth · 2021-12-11 21:19:56

You can https://wiki.archlinux.org/title/Audit_ … ies_access to log access to /dev/tty in your journal

lucasyata · 2021-12-15 20:52:17

I'm having several problems with auditd, auditctl, etc.
Probably solve them will take some (more even) time.
Sorry guys

seth · 2021-12-15 20:54:09

What problems? Maybe same cause?

lucasyata · 2022-01-03 00:49:46

Sorry guys, i couldn't connect before.
Some days ago i started to research again about my problems with auditctl.
In the process i got unlimited internet access so i took the oportunity to upgrade my system.
# doas nice -20 pacman -Syu
Yeah i replaced sudo with doas.

So it downloaded all packages and then pacman failed to install the packages due that a bunch of masterkeys were deprecated.
So i update them and pacman installed all new packages. And the xterm issue(plus other issues) got solved.

I don't know how i pass this by.
I really sorry guys

i'm adding a quick summary to the original post and closing the post.

Last edited by lucasyata (2022-01-03 00:51:50)

Arch Linux

#26 2021-12-07 04:31:47

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

#27 2021-12-07 07:51:27

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

#28 2021-12-07 15:09:13

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

#29 2021-12-07 15:31:45

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

#30 2021-12-07 16:22:09

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

#31 2021-12-07 16:56:43

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

#32 2021-12-07 17:00:33

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

#33 2021-12-07 17:38:53

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

#34 2021-12-07 17:42:56

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

#35 2021-12-07 18:29:00

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

#36 2021-12-07 18:32:37

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

#37 2021-12-07 18:36:40

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

#38 2021-12-07 18:40:09

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

#39 2021-12-07 18:54:24

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

#40 2021-12-07 19:01:00

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

#41 2021-12-07 19:36:36

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

#42 2021-12-08 02:19:42

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

#43 2021-12-08 07:11:46

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

#44 2021-12-11 19:44:59

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

#45 2021-12-11 21:19:56

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

#46 2021-12-15 20:52:17

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

#47 2021-12-15 20:54:09

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

#48 2022-01-03 00:49:46

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

Board footer