-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/11/2019 16.17, Dan Cermak wrote:
"Carlos E. R." <> writes:
On 11/11/2019 13.30, Dan Cermak wrote:
"Carlos E. R." <> writes:
On 11/11/2019 10.49, Michael Pujos wrote: > On 11/11/19 10:06 AM, Dan Cermak wrote: Hi list,
But neither does your suggestion, as it does exactly the same thing as what Michael suggested, only via a configuration file, that I never touched and that wasn't touched in the time frame in question.
Since setting setuid root was never necessary for Xorg in the past 5 years, I'd honestly like to know why it should suddenly be now (and especially why it depends on the driver that is used).
Unfortunately, startx does not work without setuid root since many years. I'm amazed that it worked for you without doing it. Rather you did the change and forgot, or somebody else did it for you. Or you loged in as root, or some unknown bug.
Well, it worked consistently for years first on Archlinux/Manjaro, later on Fedora and until last week on Tumbleweed. I have never manually set any setuid bit and (as far as I remember) setuid bits are rarely set on openSUSE and Fedora because that requires quite a bit of paperwork (for good reasons).
It is intentional not to allow startx to run.
That is news to me. Why?
Read the comment in the file I told you to edit. I remember it was discussed long ago in the mail lists, but not what was said. Ok, perhaps this old post: Date: Mon, 21 Feb 2011 14:18:55 -0000 From: ...@googlemail.com To: opensuse@opensuse.org Subject: [opensuse] Can't startx without root priviliges. Yes, first answer is authoritative and says it is intentional. You can find the whole thread in the archive: https://lists.opensuse.org/ Besides of that, startx is little maintained. [reading from a previous answer on mine on this subject] As a consequence, it lacks certain modern features, like the concept of "seat": the person that seats in front of the computer should have the permission to use sound, the cdrom, external storage devices, etc. The display manager handles giving those permission to the person that logs in, without he needing to belong to the pertinent groups. If a different person logs in, he gets the seat instead, and not the other person - who in traditional usage with groups, he still holds the permissions (normally both would have them). Look, the sound devices: cer@Telcontar:~> l /dev/snd/ total 0 drwxr-xr-x 3 root root 220 Oct 20 10:47 ./ drwxr-xr-x 22 root root 6480 Oct 21 02:35 ../ drwxr-xr-x 2 root root 60 Oct 20 10:47 by-path/ crw-rw----+ 1 root audio 116, 2 Oct 20 10:47 controlC0 crw-rw----+ 1 root audio 116, 7 Oct 20 10:47 hwC0D1 crw-rw----+ 1 root audio 116, 4 Oct 26 12:36 pcmC0D0c crw-rw----+ 1 root audio 116, 3 Oct 28 09:37 pcmC0D0p crw-rw----+ 1 root audio 116, 6 Oct 20 10:48 pcmC0D1c crw-rw----+ 1 root audio 116, 5 Oct 20 10:48 pcmC0D1p crw-rw----+ 1 root audio 116, 1 Oct 20 10:47 seq crw-rw----+ 1 root audio 116, 33 Oct 20 10:47 timer cer@Telcontar:~> See the '+' at the end of the permissions? cer@Telcontar:~> getfacl /dev/snd/controlC0 getfacl: Removing leading '/' from absolute path names # file: dev/snd/controlC0 # owner: root # group: audio user::rw- user:cer:rw- <======= group::rw- mask::rw- other::--- cer@Telcontar:~> My user, 'cer', has been granted extended access attribute. If I switch to the text terminal (ctrl-alt-f1) and log in as root, the extended attributes disappear. If on the graphic session I log on a second simultaneous session as another user, that user gets the acls. If I switch back to the first session, the first user gets the permissions back.
(The difference of "my" method is that it is the official one and is permanent.)
I wasn't meaning to bash your method, only to point out that it does the same as the suggested manual fix.
That manual fix is reverted by a cron job and by updates. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXcmmwQAKCRC1MxgcbY1H 1QZ+AJsErjx2B7jrO8PDdXefmv5TgXhnwgCcCEVNMjx9Ft37MBlSVOuBe0GPkYU= =Ap2q -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org