[yast-devel] How deal with modules executed without enough permissions?
Hi there! Today, while I was working to fix an issue when executing "yast2 system_settings" without enough permissions[1][2], some questions arose to my mind. Let me share them, * If I run "/usr/sbin/yast2" it warns about the permissions and only shows a few modules[3]. So, * Can we manage [1] and [2] in a "centralized" way? I mean, do we have a way to know in advance when the execution of a certain module will require root permissions? If the answer is NO, * Can we open a discussion/research/whatever to do something to this regard? Do you think it worth it? Or do you already had such discussions in the past? If so, what was the conclusion? Apart from these questions, a little bit off-topic but also related to the topic, I found weird that "yast2 storage" prompt a warning[4] saying > The storage subsystem is locked by an unknown application. > You must quit that application before you can continue. > > Would you like to abort or try again? when it is executed as a normal user. Actually is a problem with permissions, not an "unknown application locking the storage subsystem". Waiting for your inputs, thanks in advance. See you. [1] https://github.com/yast/yast-tune/pull/40 [2] https://github.com/yast/yast-bootloader/pull/583 [3] https://gist.github.com/dgdavid/323e5aa879490e24ea2d0d520550e1fe#gistcomment... [4] https://gist.github.com/dgdavid/323e5aa879490e24ea2d0d520550e1fe#gistcomment... -- David Díaz González YaST Team at SUSE Linux GmbH
On Mon, Nov 25, 2019 at 19:28, David Díaz
Hi there!
Today, while I was working to fix an issue when executing "yast2 system_settings" without enough permissions[1][2], some questions arose to my mind. Let me share them,
* If I run "/usr/sbin/yast2" it warns about the permissions and only shows a few modules[3]. So, * Can we manage [1] and [2] in a "centralized" way? I mean, do we have a way to know in advance when the execution of a certain module will require root permissions? If the answer is NO, * Can we open a discussion/research/whatever to do something to this regard? Do you think it worth it? Or do you already had such discussions in the past? If so, what was the conclusion?
Apart from these questions, a little bit off-topic but also related to the topic, I found weird that "yast2 storage" prompt a warning[4] saying
The storage subsystem is locked by an unknown application. You must quit that application before you can continue.
Would you like to abort or try again?
when it is executed as a normal user. Actually is a problem with permissions, not an "unknown application locking the storage subsystem".
Sounds like a job for polkit ;) The only way YaST is currently aware of a need of elevated permissions is contents of the desktop file. This however is very limited, because it only allows elevating permissions to root, even if the user has permissions to perform the actions without switching to root. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 11/25/19 7:28 PM, David Díaz wrote:
Hi there!
Today, while I was working to fix an issue when executing "yast2 system_settings" without enough permissions[1][2], some questions arose to my mind. Let me share them,
* If I run "/usr/sbin/yast2" it warns about the permissions and only shows a few modules[3]. So, * Can we manage [1] and [2] in a "centralized" way? I mean, do we have a way to know in advance when the execution of a certain module will require root permissions? If the answer is NO, * Can we open a discussion/research/whatever to do something to this regard? Do you think it worth it? Or do you already had such discussions in the past? If so, what was the conclusion?
Apart from these questions, a little bit off-topic but also related to the topic, I found weird that "yast2 storage" prompt a warning[4] saying
> The storage subsystem is locked by an unknown application. > You must quit that application before you can continue. > > Would you like to abort or try again?
when it is executed as a normal user. Actually is a problem with permissions, not an "unknown application locking the storage subsystem".
Regarding the storage message, I agree, it could be misleading. Basically, that message is shown when the lock file cannot be open (because it is already open or because whatever any other reason, e.g., lacking of permissions). Maybe we should distinguish the case and inform the user properly. I think it deserves a bug entry in bugzilla ;)
Waiting for your inputs, thanks in advance.
See you.
[1] https://github.com/yast/yast-tune/pull/40
[2] https://github.com/yast/yast-bootloader/pull/583
[3] https://gist.github.com/dgdavid/323e5aa879490e24ea2d0d520550e1fe#gistcomment...
[4] https://gist.github.com/dgdavid/323e5aa879490e24ea2d0d520550e1fe#gistcomment...
-- José Iván López González YaST Team at SUSE LINUX GmbH IRC: jilopez -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 11/25/19 8:28 PM, David Díaz wrote:
Hi there!
Today, while I was working to fix an issue when executing "yast2 system_settings" without enough permissions[1][2], some questions arose to my mind. Let me share them,
* If I run "/usr/sbin/yast2" it warns about the permissions and only shows a few modules[3]. So, * Can we manage [1] and [2] in a "centralized" way? I mean, do we have a way to know in advance when the execution of a certain module will require root permissions? If the answer is NO,
I wonder if you are aware of the existence of Yast::Confirm.MustBeRoot That's what most YaST modules seem to be using to report the situation to the user: https://github.com/search?q=org%3Ayast+MustBeRoot&type=Code Cheers -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 26/11/19 12:50, Ancor Gonzalez Sosa wrote:
On 11/25/19 8:28 PM, David Díaz wrote:
Hi there!
Today, while I was working to fix an issue when executing "yast2 system_settings" without enough permissions[1][2], some questions arose to my mind. Let me share them,
* If I run "/usr/sbin/yast2" it warns about the permissions and only shows a few modules[3]. So, * Can we manage [1] and [2] in a "centralized" way? I mean, do we have a way to know in advance when the execution of a certain module will require root permissions? If the answer is NO, I wonder if you are aware of the existence of Yast::Confirm.MustBeRoot
No, I wasn't. Thank you!
That's what most YaST modules seem to be using to report the situation to the user: https://github.com/search?q=org%3Ayast+MustBeRoot&type=Code
Cheers
-- David Díaz González YaST Team at SUSE Linux GmbH
On 25/11/19 20:05, Stasiek Michalski wrote:
[...] Sounds like a job for polkit ;)
The only way YaST is currently aware of a need of elevated permissions is contents of the desktop file. This however is very limited, because it only allows elevating permissions to root, even if the user has permissions to perform the actions without switching to root.
Thanks for the input Stasiek!
LCP [Stasiek] https://lcp.world
-- David Díaz González YaST Team at SUSE Linux GmbH
On 26/11/19 9:19, José Iván López González wrote:
[...]
Regarding the storage message, I agree, it could be misleading. Basically, that message is shown when the lock file cannot be open (because it is already open or because whatever any other reason, e.g., lacking of permissions).
Maybe we should distinguish the case and inform the user properly. I think it deserves a bug entry in bugzilla ;)
Thanks Iván. I'll fill a bug entry soon.
Waiting for your inputs, thanks in advance.
See you.
[1] https://github.com/yast/yast-tune/pull/40
[2] https://github.com/yast/yast-bootloader/pull/583
[3] https://gist.github.com/dgdavid/323e5aa879490e24ea2d0d520550e1fe#gistcomment...
[4] https://gist.github.com/dgdavid/323e5aa879490e24ea2d0d520550e1fe#gistcomment...
-- David Díaz González YaST Team at SUSE Linux GmbH
On 26/11/19 12:56, David Díaz wrote:
On 26/11/19 12:50, Ancor Gonzalez Sosa wrote:
[...] I wonder if you are aware of the existence of Yast::Confirm.MustBeRoot No, I wasn't. Thank you!
But, as discussed in the yast-bootloader PR[1], this is not a solution to manage when an specific module is running with enough permissions to perform all the intended actions. Instead, it only warns to the user that something might not work. Probably the suggestion from Stasiek[2] is right, but to be honest I wouldn't know where start :) See you. [1] https://github.com/yast/yast-bootloader/pull/583#issuecomment-558632678 [2] https://lists.opensuse.org/yast-devel/2019-11/msg00014.html
That's what most YaST modules seem to be using to report the situation to the user: https://github.com/search?q=org%3Ayast+MustBeRoot&type=Code
Cheers
-- David Díaz González YaST Team at SUSE Linux GmbH
On 25.11.19 21:05, Stasiek Michalski wrote:
Sounds like a job for polkit ;)
We discussed that a couple of times already; this idea keeps rising from the
undead, so it looks like we have to slay that beast again. ;-)
Kind regards
--
Stefan Hundhammer
Dne 25. 11. 19 v 20:28 David Díaz napsal(a): [...]
* Can we manage [1] and [2] in a "centralized" way? I mean, do we have a way to know in advance when the execution of a certain module will require root permissions? If the answer is NO,
It's complicated by the fact that some modules might call another modules, so it depends on the functionality which you will really use. You cannot tell that for sure in advance.
* Can we open a discussion/research/whatever to do something to this regard? Do you think it worth it? Or do you already had such discussions in the past? If so, what was the conclusion? I'm not sure whether we had a discussion about it in the past but there are couple of expectations which YaST has.
Running as root, or more specifically being able to read/write the configs, is one of them. In theory the admin could make the needed config files writable for a non-root user and then YaST should work fine as that user. For example I can do this (as root): setfacl -m u:lslezak:rw /etc/sysconfig/yast2 then I can run /usr/sbin/yast2 sysconfig and change the options in that (!!) file as non-root. But I do not consider that as a practically usable solution as you usually do not know which files are actually used by which YaST module. And in that case adding the hard UID == 0 check would block this scenario. Additionally even running as root does not guarantee you can read/write all files. There might be system limitations (the root partition mounted in the RO mode, the processes running in a docker container run as root but you still cannot do everything there, etc...) or there can be even hardware restrictions (SCSI hard drives have RO pins and you can jumper them to the RO mode, SD cards have that RO slider, etc...). So in the end testing UID == 0 is not the perfect solution, maybe tests like File.readable?/File.writable? might be even better... We can only make it less possible to run the YaST modules as a non-root. The YaST control center already displays the YaST modules which you can run, so that's OK. But of course, that does not prevent you from running "/usr/sbin/yast2 needs_root" manually. We can compare the behavior with running e.g. "vim /etc/fstab" as a non-root. In that case it displays "[readonly]" flag in the status bar, if you try to edit the file it displays "Warning: Changing a readonly file" there. But you can still continue editing. If you insist on writing the file you'll get the "Can't open file for writing" error in the end. Then it's up to the user what to do. Either abort so all changes are lost or write to a different file and later move it as root to the original location. Obviously we do not allow to do the second option in YaST so the user could only abort anyway. So from that perspective displaying a warning at beginning that something might fail is OK, also displaying an error when saving is OK. Crashing at some point is bad. On the other hand if it crashed it means nothing has been changed so it should be quite safe for the user. ;-) So in the end I think we should improve the error handling in general (to not crash) but I think we should not explicitly block non-root users just because we think it won't work. That might hurt in the opposite way in some cases. -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 2/12/19 17:29, Ladislav Slezak wrote:
Dne 25. 11. 19 v 20:28 David Díaz napsal(a): [...]
* Can we manage [1] and [2] in a "centralized" way? I mean, do we have a way to know in advance when the execution of a certain module will require root permissions? If the answer is NO,
It's complicated by the fact that some modules might call another modules, so it depends on the functionality which you will really use. You cannot tell that for sure in advance.
* Can we open a discussion/research/whatever to do something to this regard? Do you think it worth it? Or do you already had such discussions in the past? If so, what was the conclusion? I'm not sure whether we had a discussion about it in the past but there are couple of expectations which YaST has.
Running as root, or more specifically being able to read/write the configs, is one of them.
In theory the admin could make the needed config files writable for a non-root user and then YaST should work fine as that user. For example I can do this (as root):
setfacl -m u:lslezak:rw /etc/sysconfig/yast2
then I can run
/usr/sbin/yast2 sysconfig
and change the options in that (!!) file as non-root. But I do not consider that as a practically usable solution as you usually do not know which files are actually used by which YaST module.
And in that case adding the hard UID == 0 check would block this scenario.
Additionally even running as root does not guarantee you can read/write all files. There might be system limitations (the root partition mounted in the RO mode, the processes running in a docker container run as root but you still cannot do everything there, etc...) or there can be even hardware restrictions (SCSI hard drives have RO pins and you can jumper them to the RO mode, SD cards have that RO slider, etc...). So in the end testing UID == 0 is not the perfect solution, maybe tests like File.readable?/File.writable? might be even better...
We can only make it less possible to run the YaST modules as a non-root. The YaST control center already displays the YaST modules which you can run, so that's OK. But of course, that does not prevent you from running "/usr/sbin/yast2 needs_root" manually.
We can compare the behavior with running e.g. "vim /etc/fstab" as a non-root. In that case it displays "[readonly]" flag in the status bar, if you try to edit the file it displays "Warning: Changing a readonly file" there. But you can still continue editing. If you insist on writing the file you'll get the "Can't open file for writing" error in the end.
Then it's up to the user what to do. Either abort so all changes are lost or write to a different file and later move it as root to the original location. Obviously we do not allow to do the second option in YaST so the user could only abort anyway.
So from that perspective displaying a warning at beginning that something might fail is OK, also displaying an error when saving is OK. Crashing at some point is bad. On the other hand if it crashed it means nothing has been changed so it should be quite safe for the user. ;-)
So in the end I think we should improve the error handling in general (to not crash) but I think we should not explicitly block non-root users just because we think it won't work. That might hurt in the opposite way in some cases.
I had overlooked your detailed answer Ladislav. Thanks a lot for the info. -- David Díaz González YaST Team at SUSE Linux GmbH
participants (6)
-
Ancor Gonzalez Sosa -
David Díaz -
José Iván López González -
Ladislav Slezak -
Stasiek Michalski -
Stefan Hundhammer