To .xinitrc just before the line: exec ${CURRENTWM}, I've added the line: /root/.puppylogin/login-puppy_simple
At boot the dialog pops up, but the dialog's border & title bar are missing.
I'm guessing this is due to the WM not running yet?
So if that's the case, shouldn't the WM line be: ./${CURRENTWM}, & my added line come after that?
Q about .xinitrc & problem running GTK dialog.
yes, the wm provides the title bar and the border and other window decoration, and allows you to maximize, minimize, rollup, move, resize etc etc the windows
do you really need the title bar? ... it will probably have a Close window button that you might not want a login window to have
i thought the main idea of the login window was to prevent the wm from starting without the correct password ... if so, you would not want to start the wm until after the correct password is typed in
if you do want the wm to start when the login program starts, just put an & after the login program:
/root/.puppylogin/login-puppy_simple &
do you really need the title bar? ... it will probably have a Close window button that you might not want a login window to have
i thought the main idea of the login window was to prevent the wm from starting without the correct password ... if so, you would not want to start the wm until after the correct password is typed in
if you do want the wm to start when the login program starts, just put an & after the login program:
/root/.puppylogin/login-puppy_simple &
Last edited by GuestToo on Fri 06 Oct 2006, 22:08, edited 1 time in total.
If you'd run the WM first, and then the login, what would happen?
You'd enter a wrong password, and the login-script would exit, leaving the WM running.
So everybody could login, what means you would need no login at all.
This way to login is quite weak though, with some advanced knowledge it is easy to trick out.
It is basically intended to protect from curious colleages or your grand-ma without deeper Linux-knowledge.
If you need a strong protection, have a look at this tool from Glizl to use a encrypted mounted "virtual drive".
In this drive you could store passwords.
This approach might also be used, to create for example a symbolic symlink /root/.mozilla to a folder in this drive instead of using the folder /root/.mozilla.
Like this all your mozilla-settings and history would be saved in the encrypted file, and nobody without the password could access them.
http://www.murga.org/~puppy/viewtopic.php?p=71101#71101
Mark
You'd enter a wrong password, and the login-script would exit, leaving the WM running.
So everybody could login, what means you would need no login at all.
This way to login is quite weak though, with some advanced knowledge it is easy to trick out.
It is basically intended to protect from curious colleages or your grand-ma without deeper Linux-knowledge.
If you need a strong protection, have a look at this tool from Glizl to use a encrypted mounted "virtual drive".
In this drive you could store passwords.
This approach might also be used, to create for example a symbolic symlink /root/.mozilla to a folder in this drive instead of using the folder /root/.mozilla.
Like this all your mozilla-settings and history would be saved in the encrypted file, and nobody without the password could access them.
http://www.murga.org/~puppy/viewtopic.php?p=71101#71101
Mark
Yep, it's weak (nonexistant really), but as everyone's root user anyway, anyone can delete anything... like SAVE files.
Unless Glizl's encrypted virtual drive will stop this from happening... (don't think so).
Also the setup boots Puppy to a default SAVE file & upon login it mounts the user's SAVE on top of the default.
So the setup only mounts SAVE files for user's work spaces, not for security that can't really be.
However... users not being able to mount & view others SAVE files has merit.
If there's an interest I'll add UserName, Password, & Save file encryption.
That's why I called it: Login-Puppy_Simple (emphasis on Simple).
But the problem of a malicious user deleting SAVE files can't be solved in the current Puppies (as I see it).
When I get back to LanPuppy, Samba solves this problem because users can only access their share.
Something like this could be done for Puppy by locally mounting Samba shares to solve the problem.
Unless Glizl's encrypted virtual drive will stop this from happening... (don't think so).
Also the setup boots Puppy to a default SAVE file & upon login it mounts the user's SAVE on top of the default.
So the setup only mounts SAVE files for user's work spaces, not for security that can't really be.
However... users not being able to mount & view others SAVE files has merit.
If there's an interest I'll add UserName, Password, & Save file encryption.
That's why I called it: Login-Puppy_Simple (emphasis on Simple).
But the problem of a malicious user deleting SAVE files can't be solved in the current Puppies (as I see it).
When I get back to LanPuppy, Samba solves this problem because users can only access their share.
Something like this could be done for Puppy by locally mounting Samba shares to solve the problem.