Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #203199 > unrolled thread

Making a modal window

Back to article view | Back to linux.debian.user

Contents

  Making a modal window "J.Arun Mani" <J.ArunMani@protonmail.com> - 2018-12-09 19:30 +0100
    Re: Making a modal window Dan Ritter <dsr@randomstring.org> - 2018-12-09 19:50 +0100
      Re: Making a modal window Cindy-Sue Causey <butterflybytes@gmail.com> - 2018-12-09 20:50 +0100
      Re: Making a modal window Dan Ritter <dsr@randomstring.org> - 2018-12-10 13:50 +0100
    Re: Making a modal window Michael Lange <klappnase@freenet.de> - 2018-12-09 23:00 +0100
    Making a modal window Rusi Mody <rustompmody@gmail.com> - 2018-12-10 06:50 +0100
      Re: Making a modal window Gene Heskett <gheskett@shentel.net> - 2018-12-10 07:50 +0100
        Re: Making a modal window John Hasler <jhasler@newsguy.com> - 2018-12-10 15:20 +0100
          Re: Making a modal window Gene Heskett <gheskett@shentel.net> - 2018-12-10 16:10 +0100
      Re: Making a modal window Brian <ad44@cityscape.co.uk> - 2018-12-10 12:30 +0100
        Re: Making a modal window Greg Wooledge <wooledg@eeg.ccf.org> - 2018-12-10 15:00 +0100
        Re: Making a modal window Dave Sherohman <dave@sherohman.org> - 2018-12-10 15:30 +0100
          Re: Making a modal window Brian <ad44@cityscape.co.uk> - 2018-12-10 16:00 +0100

#203199 — Making a modal window

[Multipart message — attachments visible in raw view] — view raw

Hello,
[I'M UNSURE WHETHER IT IS THE RIGHT PLACE TO ASK THIS QUESTION. IF NOT PLEASE GUIDE ME TO THE RIGHT PLACE]
I'm making a project(using Python3) which opens whenever someone opens their computer (assume Linux-Debain based) and asks them some details. The user should not be allowed to use the computer without giving the details. The project is based on GTK3 and is for Debian based OS. I need help in the following-
How can I make the application modal? That is, make sure that the user cannot access any thing in desktop without giving the details (the application is a compulsory one, thus one should not be able to close or minimise it).

I researched on this a bit and found the answers leading to Desktop Managers. But I'm stuck how to start with them. So need some help here.

Thank You
J. Arun Mani

[toc] | [next] | [standalone]

#203200

J.Arun Mani wrote: 
> Hello,
> [I'M UNSURE WHETHER IT IS THE RIGHT PLACE TO ASK THIS QUESTION. IF NOT PLEASE GUIDE ME TO THE RIGHT PLACE]
> I'm making a project(using Python3) which opens whenever someone opens their computer (assume Linux-Debain based) and asks them some details. The user should not be allowed to use the computer without giving the details. The project is based on GTK3 and is for Debian based OS. I need help in the following-
> How can I make the application modal? That is, make sure that the user cannot access any thing in desktop without giving the details (the application is a compulsory one, thus one should not be able to close or minimise it).
> 
> I researched on this a bit and found the answers leading to Desktop Managers. But I'm stuck how to start with them. So need some help here.
> 

What degree of sophistication are you trying to guard against?

For example, if you need to guard against a six-year-old, it's
sufficient to make your program run before the window manager,
and only start a window manager if it is happy.

If you need to guard against a high-school student, you will need to
put the computer in an inaccessible room and only offer access via a
remote keyboard, mouse and screen. You'll need to disable ctrl-alt-delete
processing to prevent reboots, and ctrl-alt-Fx console
switching.

Maybe you should discuss your threat model in more depth.

-dsr-

[toc] | [prev] | [next] | [standalone]

#203202

On 12/9/18, Dan Ritter <dsr@randomstring.org> wrote:
> J.Arun Mani wrote:
>> Hello,
>> [I'M UNSURE WHETHER IT IS THE RIGHT PLACE TO ASK THIS QUESTION. IF NOT
>> PLEASE GUIDE ME TO THE RIGHT PLACE]
>> I'm making a project(using Python3) which opens whenever someone opens
>> their computer (assume Linux-Debain based) and asks them some details. The
>> user should not be allowed to use the computer without giving the details.
>> The project is based on GTK3 and is for Debian based OS. I need help in
>> the following-
>> How can I make the application modal? That is, make sure that the user
>> cannot access any thing in desktop without giving the details (the
>> application is a compulsory one, thus one should not be able to close or
>> minimise it).
>>
>> I researched on this a bit and found the answers leading to Desktop
>> Managers. But I'm stuck how to start with them. So need some help here.
>>
>
> What degree of sophistication are you trying to guard against?
>
> For example, if you need to guard against a six-year-old, it's
> sufficient to make your program run before the window manager,
> and only start a window manager if it is happy.
>
> If you need to guard against a high-school student, you will need to
> put the computer in an inaccessible room and only offer access via a
> remote keyboard, mouse and screen. You'll need to disable ctrl-alt-delete
> processing to prevent reboots, and ctrl-alt-Fx console
> switching.
>
> Maybe you should discuss your threat model in more depth.


What about either of these (basically only info gained via "apt-cache
search two step auth"):

libpam-google-authenticator - Two-step verification
ruby-saml - SAML toolkit for Ruby on Rails

Yes, I do understand they're likely not appropriate as they stand, but
maybe viewing their various files will lend some help.
libpam-google-authenticator KIND OF sounds like it's regularly
variable, but that might just mean I misunderstood its description,
not to mention its usage with which I'm not familiar.

Playing around with the keyword "saml" (Security Assertion Markup
Language?) led to more things (that led to still MORE other things).
Most notably *for me* was "keystone". Overall this became an
interesting, ever expanding topic that makes me scratch my own head as
to why a simple password login wouldn't suffice... unless this is
maybe a class project.

Then again... With an easily variable authentication, I could see both
parties having access to where the admin changes the entry key such
that the child, for example, must come forward every time to ask to
borrow that key to play online. With so many children being hurt via
their online presence, it's a great idea... *IF* one can find a method
such that other tech-savvy children can't teach one's own kids how to
override it during those every times... :D

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

[toc] | [prev] | [next] | [standalone]

#203221

Sending the mail back to the list.

J.Arun Mani wrote: 
> Thanks for your reply.
> Actually the app I'm developing is for school's computer lab. In our school's computer lab, if someone wants access the computer, they should make a entry in a register stating the name, purpose, upto the time they want to use.
> 
> I'm making the same app in a computer for the computer. No user should be able to use the computer without filling the form. We can assume normal computer users and not so of advanced level.
> 
> Can you help? Isn't there any way with Linux terminal commands which freezes the application's window?
> 

Well, you've got their name from their login, so you don't need
to gather that information again.

You can gather the actual time that they used the computer
without their intervention from the logs.

That leaves "purpose", which will be filled out by half the
students as "class work" and the other half as "rberbwbbe"
or other keyboard mashing.

Preventing use of the computer is a difficult problem: see the
discussion here:

https://www.jwz.org/xscreensaver/toolkits.html

which gives me an idea:

https://www.jwz.org/xscreensaver/faq.html

Make xscreensaver start at login time, and add your application
via "xscreensaver -command watch". It's less ridiculous than
many other notions.

-dsr-

[toc] | [prev] | [next] | [standalone]

#203207

Hi,

On Sun, 09 Dec 2018 18:03:53 +0000
"J.Arun Mani" <J.ArunMani@protonmail.com> wrote:

> Hello,
> [I'M UNSURE WHETHER IT IS THE RIGHT PLACE TO ASK THIS QUESTION. IF NOT
> PLEASE GUIDE ME TO THE RIGHT PLACE] I'm making a project(using Python3)
> which opens whenever someone opens their computer (assume Linux-Debain
> based) and asks them some details. The user should not be allowed to
> use the computer without giving the details. The project is based on
> GTK3 and is for Debian based OS. I need help in the following- How can
> I make the application modal? That is, make sure that the user cannot
> access any thing in desktop without giving the details (the application
> is a compulsory one, thus one should not be able to close or minimise
> it).
> 
> I researched on this a bit and found the answers leading to Desktop
> Managers. But I'm stuck how to start with them. So need some help here.

you might want to have a look at

https://developer.gnome.org/pygtk/stable/gdk-functions.html

The gtk.gdk.pointer_grab(), gtk.gdk.pointer_ungrab(),
gtk.gdk.keyboard_grab() and gtk.gdk.keyboard_ungrab() functions might be
able to do what you want.

Regards

Michael

[toc] | [prev] | [next] | [standalone]

#203209

[J Arun Mani]
Look up kiosk instead of DM maybe?
eg https://fedoraproject.org/wiki/Fedora_Kiosk

[Gene/Brian] Yeah I find your surprise surprising...

All operating systems (except MSDOS!) have a detailed notion of protection levels, the basic point being that all users are NOT equal.
And OS progress happens when this notion is refined more and more. For example we have users and groups
then we have ACL and cgroups and other more modern zany stuff I don't understand pretend to understand!

All having the basic requirement (like the OP) that some users be prevented from doing some things that they very much would want to do
egs
1 Try removing youtube from android
Phone and you will find it's not possible.

2 I used to teach computer science at the university. And at a time when a single large mini was shared by all there was this dilemma: Give students root access and have them learn about operating systems but putting  other people's stuff at jeopardy. Or let them be ordinary users and not be able to try out things at the OS level.

3 Parent doesn't mind child breaking the computer but would not like child to visit certain websites

[toc] | [prev] | [next] | [standalone]

#203211

On Monday 10 December 2018 00:33:21 Rusi Mody wrote:

> [J Arun Mani]
> Look up kiosk instead of DM maybe?
> eg https://fedoraproject.org/wiki/Fedora_Kiosk
>
> [Gene/Brian] Yeah I find your surprise surprising...
>
> All operating systems (except MSDOS!) have a detailed notion of
> protection levels,
Never used dos. Color Computers with os9, adding amigados, then linux 
from 1998. And the color computer is running right now. os9, now Nitros9 
is a unix like but no security other than a login password if coming in 
thru an rs232 connection.

> the basic point being that all users are NOT equal. 
This is true..

> And OS progress happens when this notion is refined more and more. For
> example we have users and groups then we have ACL and cgroups and
> other more modern zany stuff I don't understand pretend to understand!

All of which to me are not progress but bloat, slowing the machine. OTOH 
I am the only user here, and finding I have to sudo before I can run 
something just to check/read something, AND have to have the path to it 
memorized because like you, whats a cgroup? ACL's I might get used to, 
but more and more its all a PIMA, often caused by pam and its poor to 
non-existant docs, but its damned sure keeping me from doing something 
I've been doing since my first red hat 5.0 install. For instance I can 
ssh -Y from this wheezy box to any other wheezy box w/o a problem, but I 
have yet to find the magic twanger to make it Just Work to a jessie or 
stretch install. Then someone else has decreed there is no network until 
a user has logged in from the machines own keyboard.  Someone has 
decided its a security hole without understanding that they are making 
life a cast iron bitch for someone like you or me.

> All having the basic requirement (like the OP) that some users be
> prevented from doing some things that they very much would want to do
> egs
> 1 Try removing youtube from android
> Phone and you will find it's not possible.
>
> 2 I used to teach computer science at the university. And at a time
> when a single large mini was shared by all there was this dilemma:
> Give students root access and have them learn about operating systems
> but putting  other people's stuff at jeopardy. Or let them be ordinary
> users and not be able to try out things at the OS level.

The latter is not teaching CS, its teaching how to be dumb users, which 
to me is no better that mom & pop buying them a lappy and a net cable, 
they can learn that on their own, while letting a virus removal shop 
make a good living.

> 3 Parent doesn't mind child breaking the computer but would not like
> child to visit certain websites

Which is good on the face of it, but those web sites change addresses 
weekly, so its a lost cause, your 10 year old IS gonna find the porno. 
Changes in how his/her body acts is something the parents seem to have 
abdicated the explanation of such to the child, and that is a parental 
duty whether you have cows and pigs in the barn, and chickens in the 
yard, or are in the middle of star city.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#203227

Permissions, ACLs, etc aren't just there to protect the system against
malicious or incompetent users.  They also limit the damage buggy
software can do.

All the things you complain about are configurable defaults which you
should be able to change without needing to understand PAM.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#203232

On Monday 10 December 2018 09:14:05 John Hasler wrote:

> Permissions, ACLs, etc aren't just there to protect the system against
> malicious or incompetent users.  They also limit the damage buggy
> software can do.
>
> All the things you complain about are configurable defaults which you
> should be able to change without needing to understand PAM.

But in the end, the fail message seems to come from pam. Regardless of 
what else you manage to make tolerable leading up to pam. But I've since 
found gksudo, which either beats pam senseless, or works around it for 
at least one problem, that of running a decent gui based package manager 
from an ssh -Y login.

That does not however, let me run an x based application on a jessie or 
stretch install.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#203220

On Sun 09 Dec 2018 at 21:33:21 -0800, Rusi Mody wrote:

> [J Arun Mani]
> Look up kiosk instead of DM maybe?
> eg https://fedoraproject.org/wiki/Fedora_Kiosk
> 
> [Gene/Brian] Yeah I find your surprise surprising...
> 
> All operating systems (except MSDOS!) have a detailed notion of
> protection levels, the basic point being that all users are NOT equal.
> And OS progress happens when this notion is refined more and more. For
> example we have users and groups then we have ACL and cgroups and
> other more modern zany stuff I don't understand pretend to understand!
> 
> All having the basic requirement (like the OP) that some users be
> prevented from doing some things that they very much would want to do
> egs
> 1 Try removing youtube from android
> Phone and you will find it's not possible.
> 
> 2 I used to teach computer science at the university. And at a time
> when a single large mini was shared by all there was this dilemma:
> Give students root access and have them learn about operating systems
> but putting  other people's stuff at jeopardy. Or let them be ordinary
> users and not be able to try out things at the OS level.
> 
> 3 Parent doesn't mind child breaking the computer but would not like
> child to visit certain websites

It wasn't any plan for layers of secutity which surprised me but
the desire to add to the existing username/password login scheme
with extra (unspecified) questions. It seems there is nothing to
be gained from this approach.

Furthermore, the OP specified

  > ...whenever someone opens their computer

and I took "opens" to mean "switches on", which might mean having
to look at what existing DMs have in the way of this functionality
and of running another program. I believe lightdm can run scripts
at login time.

And, of course, there is always the opportunity to have an extra
question via a GRUB password.

(I hope this response raises my score above the recently awarded
0/10).

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#203226

On Mon, Dec 10, 2018 at 11:24:33AM +0000, Brian wrote:
> Furthermore, the OP specified
> 
>   > ...whenever someone opens their computer
> 
> and I took "opens" to mean "switches on", which might mean having
> to look at what existing DMs have in the way of this functionality
> and of running another program. I believe lightdm can run scripts
> at login time.

I would assume it's literal.  The OP works for some entity (government,
school, etc.) which is distributing laptops, and wants to control every
aspect of every interaction between the user and the laptop, starting
the moment the laptop is physically opened (top half separated from the
bottom half).

Of course, we already know the OP is incompetent, because instead of
telling us who they are and what they are trying to accomplish, they
led everyone on a wild guessing game.  This reinforces the "government
or school" guess.

[toc] | [prev] | [next] | [standalone]

#203228

On Mon, Dec 10, 2018 at 11:24:33AM +0000, Brian wrote:
> It wasn't any plan for layers of secutity which surprised me but
> the desire to add to the existing username/password login scheme
> with extra (unspecified) questions.

Dan Ritter's reply included some off-list clarification from the OP:

> Actually the app I'm developing is for school's computer lab. In our
> school's computer lab, if someone wants access the computer, they
> should make a entry in a register stating the name, purpose, upto the
> time they want to use.           
>                                                                               
> I'm making the same app in a computer for the computer. No user should
> be able to use the computer without filling the form. We can assume
> normal computer users and not so of advanced level. 

As Dan pointed out, you should be able to determine the user's name from
their login information and the duration of the session is also logged
automatically, so that really just leaves the "purpose" as the only
thing which still needs to be collected separately.

-- 
Dave Sherohman

[toc] | [prev] | [next] | [standalone]

#203231

On Mon 10 Dec 2018 at 07:55:32 -0600, Dave Sherohman wrote:

> On Mon, Dec 10, 2018 at 11:24:33AM +0000, Brian wrote:
> > It wasn't any plan for layers of secutity which surprised me but
> > the desire to add to the existing username/password login scheme
> > with extra (unspecified) questions.
> 
> Dan Ritter's reply included some off-list clarification from the OP:

Had I seen it on-list (Dan Ritter's mail arrived over an hour after I
sent mine) I might have structured a different response.

-- 
Brian.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web