[opensuse] a stupid sudo question
If I am attributing the system "secure rights" in yast. If I am activating group wheel for sudo. If I am taking off sudo rights for everybody else who is not wheel. If I plug now in an usb device, is the user still asked the password for root to mount the device? Or is he now unable to root any usb device (given secure settings)? Is there a way to avoid hat (if you have three users working, only he last open one is presented with the password request for opening an usb device (this is actually very annoying because if you work in one user you do not want to switch to another, to cancel the request, to to have finally the pop up coming up in the right place..... _________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postf�cher sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
19.01.2020 18:49, stakanov пишет:
If I am attributing the system "secure rights" in yast. If I am activating group wheel for sudo. If I am taking off sudo rights for everybody else who is not wheel.
If I plug now in an usb device, is the user still asked the password for root to mount the device?
Password request is from desktop GUI components and has absolutely nothing to do with sudo.
Or is he now unable to root any usb device (given secure settings)?
Is there a way to avoid hat (if you have three users working, only he last open one is presented with the password request for opening an usb device (this is actually very annoying because if you work in one user you do not want to switch to another, to cancel the request, to to have finally the pop up coming up in the right place.....
_________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data domenica 19 gennaio 2020 16:53:43 CET, Andrei Borzenkov ha scritto:
19.01.2020 18:49, stakanov пишет:
If I am attributing the system "secure rights" in yast. If I am activating group wheel for sudo. If I am taking off sudo rights for everybody else who is not wheel.
If I plug now in an usb device, is the user still asked the password for root to mount the device?
Password request is from desktop GUI components and has absolutely nothing to do with sudo.
I was going through this: password requests from desktop GUI with secure permissions are handled by PAM. So the SUDO function is independent from PAM? Rational is that I want to avoid SUDO on all users but the one for maintenance but maintain restriction on the mounting of usb devices. While I am quite sure that the network restrictions in secure settings is a question of ownership and permissions, the USB restriction appeared to be SUDO as it is a mount function. Do you know (or do anybody else know) whom to ask this? Would this be a question to be asked in factory (not that it really belongs to factory? Or Support? _________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postf�cher sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20/01/2020 10.29, stakanov wrote: | In data domenica 19 gennaio 2020 16:53:43 CET, Andrei Borzenkov ha | scritto: |> 19.01.2020 18:49, stakanov пишет: |>> If I am attributing the system "secure rights" in yast. If I am |>> activating group wheel for sudo. If I am taking off sudo rights |>> for everybody else who is not wheel. |>> |>> If I plug now in an usb device, is the user still asked the |>> password for root to mount the device? |> |> Password request is from desktop GUI components and has |> absolutely nothing to do with sudo. |> | | I was going through this: password requests from desktop GUI with | secure permissions are handled by PAM. So the SUDO function is | independent from PAM? Rational is that I want to avoid SUDO on all | users but the one for maintenance but maintain restriction on the | mounting of usb devices. While I am quite sure that the network | restrictions in secure settings is a question of ownership and | permissions, the USB restriction appeared to be SUDO as it is a | mount function. And you forget policykit :-p | Do you know (or do anybody else know) whom to ask this? Would this | be a question to be asked in factory (not that it really belongs to | factory? Or Support? Here, but I'm not familiar with what you try to do. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXiWBNAAKCRC1MxgcbY1H 1Z9qAJ4zoxhvHrFHbtzoLzcvgcwHKg//OwCeK2Hr8kcBvMwAPO6DpOPyCEWb6BI= =IlC1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data lunedì 20 gennaio 2020 11:30:14 CET, Carlos E. R. ha scritto:
On 20/01/2020 10.29, stakanov wrote: | In data domenica 19 gennaio 2020 16:53:43 CET, Andrei Borzenkov ha | | scritto: |> 19.01.2020 18:49, stakanov пишет: |>> If I am attributing the system "secure rights" in yast. If I am |>> activating group wheel for sudo. If I am taking off sudo rights |>> for everybody else who is not wheel. |>> |>> If I plug now in an usb device, is the user still asked the |>> password for root to mount the device? |> |> Password request is from desktop GUI components and has |> absolutely nothing to do with sudo. | | I was going through this: password requests from desktop GUI with | secure permissions are handled by PAM. So the SUDO function is | independent from PAM? Rational is that I want to avoid SUDO on all | users but the one for maintenance but maintain restriction on the | mounting of usb devices. While I am quite sure that the network | restrictions in secure settings is a question of ownership and | permissions, the USB restriction appeared to be SUDO as it is a | mount function.
And you forget policykit :-p
| Do you know (or do anybody else know) whom to ask this? Would this | be a question to be asked in factory (not that it really belongs to | factory? Or Support?
Here, but I'm not familiar with what you try to do.
-- Cheers / Saludos,
Carlos E. R. (from 15.1 x86_64 at Telcontar) I would wish: to maintain the (restricted) settings of "secure" within the machine. Take off the usual behavior that sudo can be done by all users and leave only a dedicated user, which will be part of wheel to be able to perform updates and installs. However this should not abolish the need to give either a root password or (that would be probably more sensible, the corresponding user password before allowing the mounting of an usb key (to avoid that a key is mounted when the machine is locked and a key is inserted.
What I am confused is about the relation of Pam, Policy kit, SUDO and their interaction. Who governs what. Useful side effect should be to understand why, if I have user A, B, and C open, a key inserted in B triggers the password for root not in B but in C(!) Thus only the last opened user is presented with the request (and I do not understand why). Once you cancel the request it reappears in the "right" user. If I could debug this while doing (and understanding) the rest, i would be very happy. _________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postf�cher sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 20/01/2020 16.38, stakanov wrote:
And you forget policykit :-p
| Do you know (or do anybody else know) whom to ask this? Would this | be a question to be asked in factory (not that it really belongs to | factory? Or Support?
Here, but I'm not familiar with what you try to do.
I would wish: to maintain the (restricted) settings of "secure" within the machine.
And that's the first hurdle, I never use secure settings. Too cumbersome.
Take off the usual behavior that sudo can be done by all users and leave only a dedicated user, which will be part of wheel to be able to perform updates and installs.
The way I have sudo set up is that only specific users can do specific commands. So I have to consider all users and command combinations that I want to allow, possibly also what options. Using always the user password.
However this should not abolish the need to give either a root password or (that would be probably more sensible, the corresponding user password before allowing the mounting of an usb key (to avoid that a key is mounted when the machine is locked and a key is inserted.
This is not controlled by sudo, but by the desktop you use. And it gets the permission, I understand, via policy kit. Some devices (sound?) get some ACLs added. cer@Telcontar:~> l /dev/audio crw-rw----+ 1 root audio 14, 4 Jan 15 18:07 /dev/audio cer@Telcontar:~> getfacl /dev/audio getfacl: Removing leading '/' from absolute path names # file: dev/audio # owner: root # group: audio user::rw- user:cer:rw- <==== group::rw- mask::rw- other::--- A user can mount an USB stick via command line and sudo, or by listing that device in fstab and adding the parameter "user". It means "any user", AFAIK.
What I am confused is about the relation of Pam, Policy kit, SUDO and their interaction. Who governs what. Useful side effect should be to understand why, if I have user A, B, and C open, a key inserted in B triggers the password for root not in B but in C(!)
Possibly because C has the "seat".
Thus only the last opened user is presented with the request (and I do not understand why). Once you cancel the request it reappears in the "right" user. If I could debug this while doing (and understanding) the rest, i would be very happy.
This is controlled by the display manager. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
20.01.2020 18:38, stakanov пишет:
What I am confused is about the relation of Pam, Policy kit, SUDO and their interaction. Who governs what.
PAM is framework for dynamically using external modules to handle user authentication. It consists of library that orchestrates modules use and external modules. Programs must be explicitly designed to support PAM and must be linked with PAM library (which is compile time decision). sudo is a program. It supports PAM for password request if available and on Linux it is normally using PAM but it does not depend on PAM in any way and can work without it (e.g. on systems where PAM does not exist). Policy kit is framework for handling user authorization. It consists of daemon that makes decision, client library and agents. Programs are linked with client library and use it to send request to daemon asking if current user (that started program) is allowed to perform specific action. Actions are defined by program, there is no exhaustive list. Daemon may request additional user authentication via agent. It is agent hat presents password prompt to user. Policy kit is entirely unrelated to PAM. Its function is more similar to that of sudo, but sudo is using own configuration mechanism to authorize users.
Useful side effect should be to understand why, if I have user A, B, and C open, a key inserted in B triggers the password for root not in B but in C(!)
Only one session is active at a time, normally removable mount is allowed for active session without additional request. Other users need root authentication by default.
Thus only the last opened user is presented with the request (and I do not understand why).
It is not clear what "last opened user" is. If this is currently active user, it is not expected to get any prompt in the first place.
Once you cancel the request it reappears in the "right" user. If I could debug this while doing (and understanding) the rest, i would be very happy.
Desktops today are using UDisks2 service, defaults (authorization for each action) is in /usr/share/polkit-1/actions/org.freedesktop.UDisks2.policy. Unfortunately udisks2 is heavily under-documented. Actions related to mount are org.freedesktop.udisks2.filesystem-mount org.freedesktop.udisks2.filesystem-mount-other-seat org.freedesktop.udisks2.filesystem-mount-system USB removables should use org.freedesktop.udisks2.filesystem-mount -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/01/2020 05.39, Andrei Borzenkov wrote: |> Useful side effect should be to understand why, if I have user A, |> B, and C open, a key inserted in B triggers the password for root |> not in B but in C(!) | Only one session is active at a time, normally removable mount is | allowed for active session without additional request. Other users | need root authentication by default. Caveat: he is using "secure mode". This might change the desktop to request the password every time. I have not checked. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXibFwwAKCRC1MxgcbY1H 1ZRoAJ9SV74qmwA+zEv27lKnOtppFSWy/ACdEkx6xiR/8aIKjr87w6Dnxsx8qVE= =edbW -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 21/01/2020 05.39, Andrei Borzenkov wrote: |> Useful side effect should be to understand why, if I have user A, |> B, and C open, a key inserted in B triggers the password for root |> not in B but in C(!) | | Only one session is active at a time, normally removable mount is | allowed for active session without additional request. Other users | need root authentication by default.
Caveat: he is using "secure mode". This might change the desktop to request the password every time. I have not checked.
-- Cheers / Saludos,
Carlos E. R. (from 15.1 x86_64 at Telcontar) No, it is an abnormality (like A.B. Normal as opposed to Hans von Delbrück, if you call the fitting subculture your own). The normal behavior is that the active session (that is the open desktop) asks for the password. Instead what happens is: the active desktop comes second if it is not the last desktop that opened in the sequence of login. That is, if ABC users, login order is BAC
In data martedì 21 gennaio 2020 10:35:12 CET, Carlos E. R. ha scritto: then C will be presented with the request to authorize while you inserted the key in A (e.g.) and there the password is not given and after a time it says: no password given when requested. But it was requested on the wrong desktop. I did raise a bug for it but never got any answer. So I decided to install a completely new system instead of upgrade this time with 15.2 but I want to understand what happens here, a) not to run again into it b) if a bug to give a better report and c) if something is there that should not be there, identify the issue. Overall it should give me a reasonable understanding of the issues and bring me to a personalized set of authorization that is not so server prone. I am running a laptop and a PC. Actually administering three PCs. And I am thinking about setting up another one and to come to better networking, so for all of this I need full patronage of permission pam and whatever is out there. Call it the end of "innocence" or the "end of patience" alike. _________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 21 Jan 2020 12:29:13 +0100 stakanov <stakanov@eclipso.eu> wrote:
On 21/01/2020 05.39, Andrei Borzenkov wrote: |> Useful side effect should be to understand why, if I have user A, |> B, and C open, a key inserted in B triggers the password for root |> not in B but in C(!) | | Only one session is active at a time, normally removable mount is | allowed for active session without additional request. Other users | need root authentication by default.
Caveat: he is using "secure mode". This might change the desktop to request the password every time. I have not checked.
-- Cheers / Saludos,
Carlos E. R. (from 15.1 x86_64 at Telcontar) No, it is an abnormality (like A.B. Normal as opposed to Hans von Delbrück, if you call the fitting subculture your own). The normal behavior is that the active session (that is the open desktop) asks for the password. Instead what happens is: the active desktop comes second if it is not the last desktop that opened in the sequence of login. That is, if ABC users, login order is BAC then C will be
In data martedì 21 gennaio 2020 10:35:12 CET, Carlos E. R. ha scritto: presented with the request to authorize while you inserted the key in A (e.g.) and there the password is not given and after a time it says: no password given when requested. But it was requested on the wrong desktop.
I think you're going to have to describe the hardware in a bit more detail. How many 'seats' (displays & keyboards)? How many USB slots, and how do they relate to the seats? i.e. what does it mean to say 'inserted the key in A'? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data martedì 21 gennaio 2020 13:38:34 CET, Dave Howorth ha scritto:
On Tue, 21 Jan 2020 12:29:13 +0100
stakanov <stakanov@eclipso.eu> wrote:
In data martedì 21 gennaio 2020 10:35:12 CET, Carlos E. R. ha scritto:
On 21/01/2020 05.39, Andrei Borzenkov wrote: |> Useful side effect should be to understand why, if I have user A, |> B, and C open, a key inserted in B triggers the password for root |> not in B but in C(!) | | Only one session is active at a time, normally removable mount is | allowed for active session without additional request. Other users | need root authentication by default.
Caveat: he is using "secure mode". This might change the desktop to request the password every time. I have not checked.
-- Cheers / Saludos,
Carlos E. R. (from 15.1 x86_64 at Telcontar)
No, it is an abnormality (like A.B. Normal as opposed to Hans von Delbrück, if you call the fitting subculture your own). The normal behavior is that the active session (that is the open desktop) asks for the password. Instead what happens is: the active desktop comes second if it is not the last desktop that opened in the sequence of login. That is, if ABC users, login order is BAC then C will be presented with the request to authorize while you inserted the key in A (e.g.) and there the password is not given and after a time it says: no password given when requested. But it was requested on the wrong desktop.
I think you're going to have to describe the hardware in a bit more detail. How many 'seats' (displays & keyboards)? How many USB slots, and how do they relate to the seats? i.e. what does it mean to say 'inserted the key in A'?
Look it is very simple and even somewhat primitive and this is what triggered the original bug report. It is one laptop, one keyboard on it, but different users are opened in sequence on it, with different rights and separate homes. This has organizational as well as privacy reasons for some of the accounts on that machine. So on this single machine are a bunch (about 6) usb ports that are handled on two distinct controllers (one usb2 and one usb 3): lsusb Bus 004 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) (this one is plugged into one of the usb plugs on the mainboard integrated controller) Bus 004 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub (this controller is a inserted pci-e hub card with three independent ports). Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 005: ID 0b05:17ba ASUSTek Computer, Inc. N10 Nano 802.11n (this one is branched on the integrated controller) Network Adapter [Realtek RTL8192CU] Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub There is one additional usb port integrated on the mainboard free for usage. No matter if you choose any mainboard integrated port on the machine, or the ones usb3 on the card, the usb key is accepted but, it will show the request of the mounting allowance on the desktop, that was the last to be opened in sequence(!). Which is of course illogical because the user inserting it on the active desktop should be presented with the request, not the "last one that was logged in". Just the active desktop user one. There is only one screen, one keyboard and one PEBKAC obviously. A, B, and C are users. Sessions are described for ease with capital letters. Thus user A opens his session is A. I could call them Alice and Bob etc. but I thought plain capitals to explain may suffice. There is no ssh or tunnel or connection or network (intended as registered machines) Desired condition: No user should be able to mount a key in automatic without giving password. As me is "the Lord in person", it shall be only me that is allowed to mount a key. No acquaintance, friend or swift passerby on a train while I have a nap. I hope now that the problematic became somewhat clearer. It is plain simple, but proves not to be, for some to be established reason. _________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Jan 21, 2020 at 4:32 PM stakanov <stakanov@eclipso.eu> wrote:
I hope now that the problematic became somewhat clearer.
I still miss desktop environment for each user and openSUSE version, as well as how exactly you start multiple sessions. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Andrei Borzenkov <arvidjaar@gmail.com> [01-21-20 08:49]:
On Tue, Jan 21, 2020 at 4:32 PM stakanov <stakanov@eclipso.eu> wrote:
I hope now that the problematic became somewhat clearer.
I still miss desktop environment for each user and openSUSE version, as well as how exactly you start multiple sessions.
as <user> startx /usr/bin/awesome -- :5 although the particular tty assignment seems to become the tty where the command is initiated rather than the tty assigned. Tumbleweed -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Jan 21, 2020 at 4:59 PM Patrick Shanahan <paka@opensuse.org> wrote:
* Andrei Borzenkov <arvidjaar@gmail.com> [01-21-20 08:49]:
On Tue, Jan 21, 2020 at 4:32 PM stakanov <stakanov@eclipso.eu> wrote:
I hope now that the problematic became somewhat clearer.
I still miss desktop environment for each user and openSUSE version, as well as how exactly you start multiple sessions.
as <user> startx /usr/bin/awesome -- :5
You are using the same display number for all three concurrent X11 sessions? And I have no idea what "as user" means - did you log in locally? Did you log in via ssh? Did you lof in via VNC/X11/whatever? You know, while I am interested in understanding what happens I am certainly not inclined to squeeze every bit of information out of you. At the end it is you who have the problem; if you are not willing to help solving it why do you expect others wasting time to do it?
although the particular tty assignment seems to become the tty where the command is initiated rather than the tty assigned.
I have no idea what it is supposed to mean.
Tumbleweed
-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Andrei Borzenkov <arvidjaar@gmail.com> [01-21-20 09:32]:
On Tue, Jan 21, 2020 at 4:59 PM Patrick Shanahan <paka@opensuse.org> wrote:
* Andrei Borzenkov <arvidjaar@gmail.com> [01-21-20 08:49]:
On Tue, Jan 21, 2020 at 4:32 PM stakanov <stakanov@eclipso.eu> wrote:
I hope now that the problematic became somewhat clearer.
I still miss desktop environment for each user and openSUSE version, as well as how exactly you start multiple sessions.
as <user> startx /usr/bin/awesome -- :5
You are using the same display number for all three concurrent X11 sessions? And I have no idea what "as user" means - did you log in locally? Did you log in via ssh? Did you lof in via VNC/X11/whatever?
have and <user> login on a tty and then invoke startx (and not as root) I can login via ssh session is multi-user (runlevel 3)
You know, while I am interested in understanding what happens I am certainly not inclined to squeeze every bit of information out of you.
I have no problem but was "informing" you of startx
At the end it is you who have the problem; if you are not willing to help solving it why do you expect others wasting time to do it?
although the particular tty assignment seems to become the tty where the command is initiated rather than the tty assigned.
I have no idea what it is supposed to mean.
"startx /usr/bin/<window-manager> -- :5" used to start the graphical session in tty5 but now ignores ":5" and starts the session in the same tty# where you invoke "startx". ps: I am not the OP. maybe I should just shut-up. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data martedì 21 gennaio 2020 16:59:18 CET, Patrick Shanahan ha scritto:
* Andrei Borzenkov <arvidjaar@gmail.com> [01-21-20 09:32]:
On Tue, Jan 21, 2020 at 4:59 PM Patrick Shanahan <paka@opensuse.org> wrote:
* Andrei Borzenkov <arvidjaar@gmail.com> [01-21-20 08:49]:
On Tue, Jan 21, 2020 at 4:32 PM stakanov <stakanov@eclipso.eu> wrote:
I hope now that the problematic became somewhat clearer.
I still miss desktop environment for each user and openSUSE version, as well as how exactly you start multiple sessions.
as <user> startx /usr/bin/awesome -- :5
You are using the same display number for all three concurrent X11 sessions? And I have no idea what "as user" means - did you log in locally? Did you log in via ssh? Did you lof in via VNC/X11/whatever?
have and <user> login on a tty and then invoke startx (and not as root) I can login via ssh session is multi-user (runlevel 3)
You know, while I am interested in understanding what happens I am certainly not inclined to squeeze every bit of information out of you.
I have no problem but was "informing" you of startx
At the end it is you who have the problem; if you are not willing to help solving it why do you expect others wasting time to do it?
although the particular tty assignment seems to become the tty where the command is initiated rather than the tty assigned.
I have no idea what it is supposed to mean.
"startx /usr/bin/<window-manager> -- :5"
used to start the graphical session in tty5 but now ignores ":5" and starts the session in the same tty# where you invoke "startx".
ps: I am not the OP. maybe I should just shut-up. why, if your ideas can prove to be useful to solve / understand the issue? I did not run that command for sure. If it was a setting prior to 42.1 this is an info I do not have.
_________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LSU.2.21.2001301124140.25726@Telcontar.valinor> On Tuesday, 2020-01-21 at 17:38 +0100, stakanov wrote:
In data martedì 21 gennaio 2020 16:59:18 CET, Patrick Shanahan ha scritto:
* Andrei Borzenkov <> [01-21-20 09:32]:
On Tue, Jan 21, 2020 at 4:59 PM Patrick Shanahan <> wrote:
* Andrei Borzenkov <> [01-21-20 08:49]:
On Tue, Jan 21, 2020 at 4:32 PM stakanov <> wrote:
I hope now that the problematic became somewhat clearer.
I still miss desktop environment for each user and openSUSE version, as well as how exactly you start multiple sessions.
as <user> startx /usr/bin/awesome -- :5
...
why, if your ideas can prove to be useful to solve / understand the issue? I did not run that command for sure. If it was a setting prior to 42.1 this is an info I do not have.
Unfotunately, startx is little maintained, and has no concept of "seat", so the modern permission model for the desktop is blown out of the window. - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXjKu+Bwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVxJMAnjKCxF2Ez5vwijO9hHss 92qjMH78AJ9wM2iHruLM+ny4uO3n4OiIfWNA0A== =XAPG -----END PGP SIGNATURE-----
* Patrick Shanahan <paka@opensuse.org> [01-21-20 11:34]:
* Andrei Borzenkov <arvidjaar@gmail.com> [01-21-20 09:32]:
On Tue, Jan 21, 2020 at 4:59 PM Patrick Shanahan <paka@opensuse.org> wrote:
* Andrei Borzenkov <arvidjaar@gmail.com> [01-21-20 08:49]:
On Tue, Jan 21, 2020 at 4:32 PM stakanov <stakanov@eclipso.eu> wrote:
I hope now that the problematic became somewhat clearer.
I still miss desktop environment for each user and openSUSE version, as well as how exactly you start multiple sessions.
as <user> startx /usr/bin/awesome -- :5
You are using the same display number for all three concurrent X11 sessions? And I have no idea what "as user" means - did you log in locally? Did you log in via ssh? Did you lof in via VNC/X11/whatever?
have and <user> login on a tty and then invoke startx (and not as root) s/"have and <user>"/"have a <user>"
I can login via ssh session is multi-user (runlevel 3)
You know, while I am interested in understanding what happens I am certainly not inclined to squeeze every bit of information out of you.
I have no problem but was "informing" you of startx
At the end it is you who have the problem; if you are not willing to help solving it why do you expect others wasting time to do it?
although the particular tty assignment seems to become the tty where the command is initiated rather than the tty assigned.
I have no idea what it is supposed to mean.
"startx /usr/bin/<window-manager> -- :5"
used to start the graphical session in tty5 but now ignores ":5" and starts the session in the same tty# where you invoke "startx".
ps: I am not the OP. maybe I should just shut-up.
-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data martedì 21 gennaio 2020 14:43:22 CET, Andrei Borzenkov ha scritto:
On Tue, Jan 21, 2020 at 4:32 PM stakanov <stakanov@eclipso.eu> wrote:
I hope now that the problematic became somewhat clearer.
I still miss desktop environment for each user and openSUSE version, as well as how exactly you start multiple sessions.
My bad, as I am always on the "KDE is default thought". Multiple session are started from KDE with sddm as session manager and "start new session". However I do never start multiple sessions for the same user. /home is on a separate partition see also below the listing of devices. OS: Leap 15.1 "standard" that is with no extra KDE repos. Plasma 5 is login and X server is used (not wayland). Settings are "secure" via yast. It is a situation were, on a single machine, several person or personality are using the machine the same day. The previous user stay logged in. KDE Plasma 5.12.8 KDE Frameworks 5.55.0 QT 5.9.7 uname -a Linux roadrunner.suse 4.12.14-lp151.28.36-default #1 SMP Fri Dec 6 13:50:27 UTC 2019 (8f4a495) x86_64 x86_64 x86_64 GNU/Linux lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 477G 0 disk ├─sda1 8:1 0 399M 0 part └─sda2 8:2 0 476,6G 0 part └─cr_sda2 254:0 0 476,6G 0 crypt ├─system-root 254:1 0 20G 0 lvm / ├─system-swap 254:2 0 7,6G 0 lvm [SWAP] └─system-home 254:3 0 449G 0 lvm /home the problem with the usb key is present since upgrade from 42.1 to the next version. Anything else you wish to know? Anything omitted? _________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postf�cher sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
21.01.2020 17:46, stakanov пишет:
In data martedì 21 gennaio 2020 14:43:22 CET, Andrei Borzenkov ha scritto:
On Tue, Jan 21, 2020 at 4:32 PM stakanov <stakanov@eclipso.eu> wrote:
I hope now that the problematic became somewhat clearer.
I still miss desktop environment for each user and openSUSE version, as well as how exactly you start multiple sessions.
My bad, as I am always on the "KDE is default thought". Multiple session are started from KDE with sddm as session manager and "start new session". However I do never start multiple sessions for the same user. /home is on a separate partition see also below the listing of devices.
I tested on Leap 15.1 with XFCE + lightdm. I added custom polkit rule to force root authentication for active session. I switched user using dm-tool switch-to-user (I did not find XFCE GUI element for it). dm-tool talks to lightdm and makes it allocate new session or switch to existing one. I logged in as user u1, u2, u3, then switched to u2 session and checked that u2 session was active. After inserting USB stick I got password request for u2. I checked process list that there was just one active password request. After cancelling this request it was started for another user. In this case it was u3. Switching to u3 and cancelling request now started request for u1. So it seems to basically work as expected. I do not know how exactly requests are ordered (it was new to me that request would be cycled across all current sessions).
OS: Leap 15.1 "standard" that is with no extra KDE repos. Plasma 5 is login and X server is used (not wayland). Settings are "secure" via yast.
It is a situation were, on a single machine, several person or personality are using the machine the same day. The previous user stay logged in.
KDE Plasma 5.12.8 KDE Frameworks 5.55.0 QT 5.9.7 uname -a Linux roadrunner.suse 4.12.14-lp151.28.36-default #1 SMP Fri Dec 6 13:50:27 UTC 2019 (8f4a495) x86_64 x86_64 x86_64 GNU/Linux
lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 477G 0 disk ├─sda1 8:1 0 399M 0 part └─sda2 8:2 0 476,6G 0 part └─cr_sda2 254:0 0 476,6G 0 crypt ├─system-root 254:1 0 20G 0 lvm / ├─system-swap 254:2 0 7,6G 0 lvm [SWAP] └─system-home 254:3 0 449G 0 lvm /home
the problem with the usb key is present since upgrade from 42.1 to the next version.
Anything else you wish to know? Anything omitted?
Yes - you said you opened session for user C and then switched to session of user B. How exactly? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
21.01.2020 17:46, stakanov пишет:
In data martedì 21 gennaio 2020 14:43:22 CET, Andrei Borzenkov ha scritto:
On Tue, Jan 21, 2020 at 4:32 PM stakanov <stakanov@eclipso.eu> wrote:
I hope now that the problematic became somewhat clearer.
I still miss desktop environment for each user and openSUSE version, as well as how exactly you start multiple sessions.
My bad, as I am always on the "KDE is default thought". Multiple session are started from KDE with sddm as session manager and "start new session". However I do never start multiple sessions for the same user. /home is on a separate partition see also below the listing of devices. I tested on Leap 15.1 with XFCE + lightdm. I added custom polkit rule to force root authentication for active session. I switched user using dm-tool switch-to-user (I did not find XFCE GUI element for it). dm-tool talks to lightdm and makes it allocate new session or switch to existing one.
I logged in as user u1, u2, u3, then switched to u2 session and checked that u2 session was active. After inserting USB stick I got password request for u2. I checked process list that there was just one active password request. After cancelling this request it was started for another user. In this case it was u3. Switching to u3 and cancelling request now started request for u1.
So it seems to basically work as expected. I do not know how exactly requests are ordered (it was new to me that request would be cycled across all current sessions).
OS: Leap 15.1 "standard" that is with no extra KDE repos. Plasma 5 is login and X server is used (not wayland). Settings are "secure" via yast.
It is a situation were, on a single machine, several person or personality are using the machine the same day. The previous user stay logged in.
KDE Plasma 5.12.8 KDE Frameworks 5.55.0 QT 5.9.7 uname -a Linux roadrunner.suse 4.12.14-lp151.28.36-default #1 SMP Fri Dec 6 13:50:27 UTC 2019 (8f4a495) x86_64 x86_64 x86_64 GNU/Linux
lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 477G 0 disk ├─sda1 8:1 0 399M 0 part └─sda2 8:2 0 476,6G 0 part
└─cr_sda2 254:0 0 476,6G 0 crypt
├─system-root 254:1 0 20G 0 lvm / ├─system-swap 254:2 0 7,6G 0 lvm [SWAP] └─system-home 254:3 0 449G 0 lvm /home
the problem with the usb key is present since upgrade from 42.1 to the next version.
Anything else you wish to know? Anything omitted?
Yes - you said you opened session for user C and then switched to session of user B. How exactly? oh well, in general I am using two methods. Seldomly via KDE Plasma applet in the startup button (change user). If not with ctrl+alt+Fn (that is if the last open session is e.g. F9 to go to
In data martedì 21 gennaio 2020 19:10:51 CET, Andrei Borzenkov ha scritto: the second user (uB) you go ctrl + alt +F8. _________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postf�cher sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
21.01.2020 21:10, Andrei Borzenkov пишет:
21.01.2020 17:46, stakanov пишет:
In data martedì 21 gennaio 2020 14:43:22 CET, Andrei Borzenkov ha scritto:
On Tue, Jan 21, 2020 at 4:32 PM stakanov <stakanov@eclipso.eu> wrote:
I hope now that the problematic became somewhat clearer.
I still miss desktop environment for each user and openSUSE version, as well as how exactly you start multiple sessions.
My bad, as I am always on the "KDE is default thought". Multiple session are started from KDE with sddm as session manager and "start new session". However I do never start multiple sessions for the same user. /home is on a separate partition see also below the listing of devices.
I tested on Leap 15.1 with XFCE + lightdm. I added custom polkit rule to force root authentication for active session. I switched user using dm-tool switch-to-user (I did not find XFCE GUI element for it). dm-tool talks to lightdm and makes it allocate new session or switch to existing one.
I logged in as user u1, u2, u3, then switched to u2 session and checked that u2 session was active. After inserting USB stick I got password request for u2. I checked process list that there was just one active password request. After cancelling this request it was started for another user. In this case it was u3. Switching to u3 and cancelling request now started request for u1.
So it seems to basically work as expected.
Or may be our expectations are wrong actually.
I do not know how exactly requests are ordered (it was new to me that request would be cycled across all current sessions).
There is no "request that cycles". Monitoring org.freedesktop.UDisks2 address - when USB stick is inserted there are *three* mount requests from each session. These request are sent to the same D-Bus destination and so retrieved sequentially. If the first mount request succeeds, two others simply fail (you just do not see it). If the first request is cancelled, udisksd attempts to mount again when it starts processing next request. I do not think order of mount requests is predictable. It may be deterministic for a given system configuration, but it may change at any point (e.g. after kernel update). So either udisksd need to (optionally) reject mount request from non-active session or desktop environment need to ignore new device when session is not active and not send mount request. Whether something like this can be configured in KDE (or any other desktop environment for this matter) I do not know. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
21.01.2020 21:10, Andrei Borzenkov пишет:
21.01.2020 17:46, stakanov пишет:
In data martedì 21 gennaio 2020 14:43:22 CET, Andrei Borzenkov ha scritto:
On Tue, Jan 21, 2020 at 4:32 PM stakanov <stakanov@eclipso.eu> wrote:
I hope now that the problematic became somewhat clearer.
I still miss desktop environment for each user and openSUSE version, as well as how exactly you start multiple sessions.
My bad, as I am always on the "KDE is default thought". Multiple session are started from KDE with sddm as session manager and "start new session". However I do never start multiple sessions for the same user. /home is on a separate partition see also below the listing of devices.> I tested on Leap 15.1 with XFCE + lightdm. I added custom polkit rule to force root authentication for active session. I switched user using dm-tool switch-to-user (I did not find XFCE GUI element for it). dm-tool talks to lightdm and makes it allocate new session or switch to existing one.
I logged in as user u1, u2, u3, then switched to u2 session and checked that u2 session was active. After inserting USB stick I got password request for u2. I checked process list that there was just one active password request. After cancelling this request it was started for another user. In this case it was u3. Switching to u3 and cancelling request now started request for u1.
So it seems to basically work as expected.
Or may be our expectations are wrong actually.
I do not know how exactly requests are ordered (it was new to me that request would be cycled across all current sessions).
There is no "request that cycles". Monitoring org.freedesktop.UDisks2 address - when USB stick is inserted there are *three* mount requests from each session. These request are sent to the same D-Bus destination and so retrieved sequentially. If the first mount request succeeds, two others simply fail (you just do not see it). If the first request is cancelled, udisksd attempts to mount again when it starts processing next request.
I do not think order of mount requests is predictable. It may be deterministic for a given system configuration, but it may change at any point (e.g. after kernel update).
So either udisksd need to (optionally) reject mount request from non-active session or desktop environment need to ignore new device when session is not active and not send mount request. Whether something like this can be configured in KDE (or any other desktop environment for this matter) I do not know. For sure there must be some mechanism that rules this, because the problem I face, I "just" face it on this installation. Although it is true that I use
In data martedì 21 gennaio 2020 19:56:10 CET, Andrei Borzenkov ha scritto: this very extensively compared with other machines. I could ask on the kde list. I would therefore like to ask you for your permission to cite this email exchange, evtl with some text excerpts from here. If you do not bother, obviously. _________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postf�cher sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
21.01.2020 22:08, stakanov пишет:
In data martedì 21 gennaio 2020 19:56:10 CET, Andrei Borzenkov ha scritto:
21.01.2020 21:10, Andrei Borzenkov пишет:
21.01.2020 17:46, stakanov пишет:
In data martedì 21 gennaio 2020 14:43:22 CET, Andrei Borzenkov ha scritto:
On Tue, Jan 21, 2020 at 4:32 PM stakanov <stakanov@eclipso.eu> wrote:
I hope now that the problematic became somewhat clearer.
I still miss desktop environment for each user and openSUSE version, as well as how exactly you start multiple sessions.
My bad, as I am always on the "KDE is default thought". Multiple session are started from KDE with sddm as session manager and "start new session". However I do never start multiple sessions for the same user. /home is on a separate partition see also below the listing of devices.> I tested on Leap 15.1 with XFCE + lightdm. I added custom polkit rule to force root authentication for active session. I switched user using dm-tool switch-to-user (I did not find XFCE GUI element for it). dm-tool talks to lightdm and makes it allocate new session or switch to existing one.
I logged in as user u1, u2, u3, then switched to u2 session and checked that u2 session was active. After inserting USB stick I got password request for u2. I checked process list that there was just one active password request. After cancelling this request it was started for another user. In this case it was u3. Switching to u3 and cancelling request now started request for u1.
So it seems to basically work as expected.
Or may be our expectations are wrong actually.
I do not know how exactly requests are ordered (it was new to me that request would be cycled across all current sessions).
There is no "request that cycles". Monitoring org.freedesktop.UDisks2 address - when USB stick is inserted there are *three* mount requests from each session. These request are sent to the same D-Bus destination and so retrieved sequentially. If the first mount request succeeds, two others simply fail (you just do not see it). If the first request is cancelled, udisksd attempts to mount again when it starts processing next request.
I do not think order of mount requests is predictable. It may be deterministic for a given system configuration, but it may change at any point (e.g. after kernel update).
So either udisksd need to (optionally) reject mount request from non-active session or desktop environment need to ignore new device when session is not active and not send mount request. Whether something like this can be configured in KDE (or any other desktop environment for this matter) I do not know. For sure there must be some mechanism that rules this, because the problem I face, I "just" face it on this installation.
As with every race condition it is dependent on exact environment.
Although it is true that I use this very extensively compared with other machines. I could ask on the kde list. I would therefore like to ask you for your permission to cite this email exchange, evtl with some text excerpts from here.
Fine. It is public domain anyway :) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 21 Jan 2020 20:08:52 +0100 stakanov <stakanov@eclipso.eu> wrote:
21.01.2020 21:10, Andrei Borzenkov пишет:
21.01.2020 17:46, stakanov пишет:
In data martedì 21 gennaio 2020 14:43:22 CET, Andrei Borzenkov ha scritto:
On Tue, Jan 21, 2020 at 4:32 PM stakanov <stakanov@eclipso.eu> wrote:
I hope now that the problematic became somewhat clearer.
I still miss desktop environment for each user and openSUSE version, as well as how exactly you start multiple sessions.
My bad, as I am always on the "KDE is default thought". Multiple session are started from KDE with sddm as session manager and "start new session". However I do never start multiple sessions for the same user. /home is on a separate partition see also below the listing of devices.> I tested on Leap 15.1 with XFCE + lightdm. I added custom polkit rule to force root authentication for active session. I switched user using dm-tool switch-to-user (I did not find XFCE GUI element for it). dm-tool talks to lightdm and makes it allocate new session or switch to existing one.
I logged in as user u1, u2, u3, then switched to u2 session and checked that u2 session was active. After inserting USB stick I got password request for u2. I checked process list that there was just one active password request. After cancelling this request it was started for another user. In this case it was u3. Switching to u3 and cancelling request now started request for u1.
So it seems to basically work as expected.
Or may be our expectations are wrong actually.
I do not know how exactly requests are ordered (it was new to me that request would be cycled across all current sessions).
There is no "request that cycles". Monitoring org.freedesktop.UDisks2 address - when USB stick is inserted there are *three* mount requests from each session. These request are sent to the same D-Bus destination and so retrieved sequentially. If the first mount request succeeds, two others simply fail (you just do not see it). If the first request is cancelled, udisksd attempts to mount again when it starts processing next request.
I do not think order of mount requests is predictable. It may be deterministic for a given system configuration, but it may change at any point (e.g. after kernel update).
So either udisksd need to (optionally) reject mount request from non-active session or desktop environment need to ignore new device when session is not active and not send mount request. Whether something like this can be configured in KDE (or any other desktop environment for this matter) I do not know. For sure there must be some mechanism that rules this, because the
In data martedì 21 gennaio 2020 19:56:10 CET, Andrei Borzenkov ha scritto: problem I face, I "just" face it on this installation. Although it is true that I use this very extensively compared with other machines. I could ask on the kde list.
From Andrei's description, it doesn't seem that this is a KDE-specific problem, there should be a solution for every desktop environment (and maybe some already have it and some don't or maybe the solution should be placed elsewhere). So it seems to me that raising a bug would be the right thing to do, on opensuse's bugzilla to start with.
I would therefore like to ask you for your permission to cite this email exchange, evtl with some text excerpts from here. If you do not bother, obviously.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
21.01.2020 21:56, Andrei Borzenkov пишет:
So either udisksd need to (optionally) reject mount request from non-active session or desktop environment need to ignore new device when session is not active and not send mount request. Whether something like this can be configured in KDE (or any other desktop environment for this matter) I do not know.
Which is actually pretty much obvious - just create polkit rule to reject mount from inactive session ... adjust as needed. cat /etc/polkit-1/rules.d/00-automount.rules polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.udisks2.filesystem-mount") { if (subject.local) { if (subject.active) { return "auth_admin"; } else { return "no"; } } } }); // vim: syntax=javascript Of course, the problem is not limited to removable devices. E.g. every running user will get prompt about available updates etc. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/01/2020 14.17, stakanov wrote: | There is one additional usb port integrated on the mainboard free | for usage. No matter if you choose any mainboard integrated port on | the machine, or the ones usb3 on the card, the usb key is accepted | but, it will show the request of the mounting allowance on the | desktop, that was the last to be opened in sequence(!). Try with a different display manager. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXicAEwAKCRC1MxgcbY1H 1cQxAJ0eyKKrUqteDhSoBeBU8g0Dx4eBPQCfcdtnC40E/pj1HEeamrE5eCoY6q0= =MNag -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Mon, 20 Jan 2020, stakanov wrote: [..]
Take off the usual behavior that sudo can be done by all users and leave only a dedicated user, which will be part of wheel to be able to perform updates and installs.
That's a broken sudoers default as used elsewhere (e.g. *buntu)... My setup allows some (i.e. in my case one) user some specific commands, with usually specific arguments (usually none, as the commands often are scripts that do just that one thing). Actually, that user/command combination is usually set with "NOPASSWD", as the user can't do anything but call the command. What it boils down to is: ==== Defaults targetpw Defaults always_set_home Defaults env_reset Defaults env_keep = "DISPLAY TERM LANG" Defaults env_check = "DISPLAY TERM LANG" Defaults passwd_timeout=1 Defaults timestamp_timeout=0 Defaults insults root ALL=(ALL) ALL user localhost=(root) NOPASSWD:/usr/local/bin/foo "" [..] ==== ==== See: man 5 sudoers ==== timestamp_timeout [..] Set this to 0 to always prompt for a password. ==== As specifying commands _and_ allowed arguments correctly in sudoers is rather tricky (and unintuitive), I mostly use simple wrapperscripts, which are usually written in a way that they accept no parameters (and ignore any if given) and are mode 700. And usually, I alias the actual call to the script to the command (or put another wrapper (to more than one) in my ~/bin if I want to be able to call it from outside my shell). I.e. alias foo='sudo /usr/local/bin/foo' or ==== ~/bin/foo ==== #!/bin/sh exec /usr/bin/sudo /usr/local/bin/foo "$@" ==== The "$@" is a sample case if one wants and is allowed to pass args. In any case, all I usually have to type as a user is 'foo'. And you can easily group users if you have such a need, see the manpage.
However this should not abolish the need to give either a root password or (that would be probably more sensible, the corresponding user password before allowing the mounting of an usb key (to avoid that a key is mounted when the machine is locked and a key is inserted.
Can't help you there with all that systemd/udisks/polkit/dbus stuff going on. I use only dbus (and that limited to some KDE/Gnome stuff, e.g. kaffeine). Usually, if no KDE or other stuff is running, qdbus outputs rather little: $ qdbus :1.0 org.freedesktop.DBus $ HTH, -dnh -- "`That young girl is one of the least benightedly unintelligent organic life forms it has been my profound lack of pleasure not to be able to avoid meeting.'" -- Marvin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op zondag 19 januari 2020 16:49:59 CET schreef stakanov:
If I am attributing the system "secure rights" in yast. If I am activating group wheel for sudo. If I am taking off sudo rights for everybody else who is not wheel.
If I plug now in an usb device, is the user still asked the password for root to mount the device? Or is he now unable to root any usb device (given secure settings)?
Is there a way to avoid hat (if you have three users working, only he last open one is presented with the password request for opening an usb device (this is actually very annoying because if you work in one user you do not want to switch to another, to cancel the request, to to have finally the pop up coming up in the right place.....
_________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postf�cher sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de Have a look at the Help in YaST's Sudo module.
-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data domenica 19 gennaio 2020 16:58:22 CET, Knurpht-openSUSE ha scritto:
Op zondag 19 januari 2020 16:49:59 CET schreef stakanov:
If I am attributing the system "secure rights" in yast. If I am activating group wheel for sudo. If I am taking off sudo rights for everybody else who is not wheel.
If I plug now in an usb device, is the user still asked the password for root to mount the device? Or is he now unable to root any usb device (given secure settings)?
Is there a way to avoid hat (if you have three users working, only he last open one is presented with the password request for opening an usb device (this is actually very annoying because if you work in one user you do not want to switch to another, to cancel the request, to to have finally the pop up coming up in the right place.....
_________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postf�cher sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de
Have a look at the Help in YaST's Sudo module.
@Andrei and Knurpht: Thanks to both of you, both answers highly useful to me! _________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postf�cher sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am Sonntag, 19. Januar 2020, 17:08:11 CET schrieb stakanov:
@Andrei and Knurpht:
Thanks to both of you, both answers highly useful to me!
I once wrote down notes on how to switch openSUSE's behaviour from root user to sudo. It's a few years old and maybe outdated, but perhaps you'll find useful bits there: https://vinzv.de/en/opensuse-with-sudo-but-convenient/ Regards, vinz. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data lunedì 20 gennaio 2020 15:27:15 CET, Vinzenz Vietzke ha scritto:
Am Sonntag, 19. Januar 2020, 17:08:11 CET schrieb stakanov:
@Andrei and Knurpht:
Thanks to both of you, both answers highly useful to me!
I once wrote down notes on how to switch openSUSE's behaviour from root user to sudo. It's a few years old and maybe outdated, but perhaps you'll find useful bits there: https://vinzv.de/en/opensuse-with-sudo-but-convenient/
Regards, vinz. Dear Vinz, I am dead sure that I will find all of this useful (nothing is a grateful for a drop of rain, than a desert soil, may it be a small or large one doesn't matter. :-) ). Thank you very much. Very appreciated.
_________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (8)
-
Andrei Borzenkov -
Carlos E. R. -
Dave Howorth -
David Haller -
Knurpht-openSUSE -
Patrick Shanahan -
stakanov -
Vinzenz Vietzke