Screen Lock accepting ANY password

Please post any bugs you have found
Message
Author
ClareOldie

Screen Lock accepting ANY password

#1 Post by ClareOldie »

I just tried the screen lock facility and it appears to work except that when anyone wishes to regain access to the computer any password at all is accepted.
Not much security in that I'm afraid.

I manually deleted the .xlockrc file just to be sure but no improvement.

Does it work for everyone else?

Puppy 1.07 HDD install

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#2 Post by BarryK »

Yep, we know about this bug.

ClareOldie

ScreenLock

#3 Post by ClareOldie »

Sorry didn't mean to clutter up the forum.

Is the bug expected to be fixed soon?

User avatar
Flash
Official Dog Handler
Posts: 13071
Joined: Wed 04 May 2005, 16:04
Location: Arizona USA

#4 Post by Flash »

I haven't tried it so I really don't know anything about it, but is it possible that it's a feature not a bug, that screen lock accepts any password by default until you have set a password?

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#5 Post by BarryK »

Nup, it's a bug.

I recompiled the program with different config options, still got the same bug.

Actually, I'm using "xlockmore", which is a continuation of the original "xlock" project -- well, I may try the actual xlock source next.

If anyone is interested to try it, here are the configure options that I used:

Code: Select all

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=i486-pc-linux-gnu --enable-xlockrc --without-motif --without-editres --without-gltt --without-ftgl --without-opengl --without-mesa --without-dtsaver --without-rplay --without-nas --enable-nice-only --without-ttf --without-freetype

User avatar
jmarsden
Posts: 265
Joined: Sat 31 Dec 2005, 22:18
Location: California, USA

#6 Post by jmarsden »

I'd at least considering the possibility that xlockmore just needs some config tweaks related to password lookup. A quick look suggests that in xlock/passwd.c there are a lot of #ifdefs trying to work out what form of password file / shadow / PAM support a machine has. It's at least possible that this code is "guessing wrong" for Puppy. Since that code derives from the older xlock, if my suspicion about this is correct, that older code will also "guess wrong" in the same way. So, FWIW, my suggestion would be to troubleshoot / debug current xlockmore code, rather than regress back to (very old) original xlock code.

If the current usr_devx.sfs had included the usual trace tools like strace and ltrace, I'd have confirmed my suspicions by now... but they seem to be missing. Is there any technical reason for their absence? (I have the same question for the script command, too? I already compiled and installed that one -- I use it a lot for keeping track of manual build sessions).

I'm out of time for this tonight. I may try to compile the trace tools and see what they tell me when xlock is run with them -- just not right now :-)

Jonathan

User avatar
MU
Posts: 13649
Joined: Wed 24 Aug 2005, 16:52
Location: Karlsruhe, Germany
Contact:

#7 Post by MU »

ClareOldie, meanwhile you could this one:
http://www.murga.org/~puppy/viewtopic.php?p=18059#18059
Mark

billstclair
Posts: 106
Joined: Mon 27 Feb 2006, 01:23
Location: Upstate New York
Contact:

#8 Post by billstclair »

Removing the --enable-xlockrc option worked for me. That's labelled as "for unknown shadow password" in ./configure --help

I got a working password with:

./configure --disable-bomb --without-opengl --without-mesa

I may have some non-standard libraries installed, however, so you may need to disable more for the distribution.

The password validation area is now much smaller, however.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#9 Post by BarryK »

billstclair wrote:Removing the --enable-xlockrc option worked for me. That's labelled as "for unknown shadow password" in ./configure --help

I got a working password with:

./configure --disable-bomb --without-opengl --without-mesa

I may have some non-standard libraries installed, however, so you may need to disable more for the distribution.

The password validation area is now much smaller, however.
But that "xlockrc" is what holds the password, um, in ~/.xlockrc I think.
So, how does the password part of it work without this option? ...like, where does the password get stored?, how do you set it?

billstclair
Posts: 106
Joined: Mon 27 Feb 2006, 01:23
Location: Upstate New York
Contact:

#10 Post by billstclair »

--enable-xlockrc is misnamed. If you leave it out, xlock still asks for a password, and still stores the encoded password in .xlockrc. At least that's how mine works. Give it a try, configuring with that single option removed from your "configure..." command.

User avatar
jmarsden
Posts: 265
Joined: Sat 31 Dec 2005, 22:18
Location: California, USA

#11 Post by jmarsden »

I tried:

Code: Select all

 ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=i486-pc -linux-gnu --without-motif --without-editres --without-gltt --without-ftgl --without-opengl --without-mesa --without-dtsaver --without-rplay --without-nas --enable-nice-only --without-ttf --without-freetype
No real difference by default. However, I found that if I have a password set on the root account (set using passwd) things then work the way I expect -- xlock prompts for my account password. Then... I put the Puppy-supplied xlock binary back and tried again... and it still worked that way. Hmmm. Then I reset the root password to an empty one... and xlock still works fine!

At little more experimenting suggests that, as long as I have a non-empty password field in /etc/shadow, xlock (as supplied with Puppy) works. This applies even when the encrypted password is in fact an empty password.

So, the way to get more useful xlock behaviour in Puppy 1.07 and 1.08 (I tested both), without setting a real root password, is to use the passwd command at a shell prompt and just press Enter when prompted for the new password. After that, /etc/shadow has an encrypted pw in it which decrypts to the empty password, and xlock uses the one stored in ~/.xlockrc

If you set an actual password for the root account (a good idea if you actually care about locking your PC, in my view!), xlock will then unlock with either the one it has encrypted into ~/.xlockrc or the account password.

I suspect that Puppy just needs to ship with an encrypted empty pw in its supplied /etc/shadow to make xlock work the way BarryK wants it to?

Jonathan

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#12 Post by BarryK »

Jonathan,
That's amazing detective work!

Okay, /etc/shadow with empty password now in puppy2.

The only thing not working with xlockmore now, is it is supposed to respond to a mouse movement, but doesn't -- you have to press a key on keyboard to unlock.

User avatar
dvw86
Posts: 636
Joined: Thu 05 May 2005, 00:55
Location: Washington State

#13 Post by dvw86 »

BarryK wrote: Okay, /etc/shadow with empty password now in puppy2.
Can that fix make it into 1.0.9 as well?

User avatar
jmarsden
Posts: 265
Joined: Sat 31 Dec 2005, 22:18
Location: California, USA

#14 Post by jmarsden »

BarryK wrote:The only thing not working with xlockmore now, is it is supposed to respond to a mouse movement, but doesn't -- you have to press a key on keyboard to unlock.
You just need to add the -mousemotion option to get that effect. Adding it into /etc/xlockscreenparams is all it takes :-)

(One day we should talk about why you use all these strange little tiny config files that lack a trailing LF ... which seems very non-standard to me.... but anyway... here's the relevant unified diff for /usr/local/apps/Xlock/AppRun

Code: Select all

23:03:11 root@jm:/usr/local/apps/Xlock# diff -u AppRun.orig AppRun
--- AppRun.orig 2006-03-07 23:02:11.000000000 -0800
+++ AppRun      2006-03-07 23:02:54.000000000 -0800
@@ -4,7 +4,7 @@
 PARAM1="$1"
 
 if [ ! -f /etc/xlockscreenparams ];then
- echo -n ' -grabserver -echokeys -echokey X -mode goop'  > /etc/xlockscreenparams
+ echo -n ' -mousemotion -grabserver -echokeys -echokey X -mode goop'  > /etc/xlockscreenparams
 fi
 if [ ! -f /etc/xlockrootparams ];then
  echo -n ' -bg white -inroot -mode goop'  > /etc/xlockrootparams
Jonathan

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#15 Post by Lobster »

Jonathan can you give an example and a way to implement better / simpler / more appropriate / more efficient please ;) 8)

Thanks as always
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

User avatar
jmarsden
Posts: 265
Joined: Sat 31 Dec 2005, 22:18
Location: California, USA

#16 Post by jmarsden »

Lobster wrote:Jonathan can you give an example and a way to implement better / simpler / more appropriate / more efficient please
That's really a whole new thread, but OK.

Say you have a script that needs to use 3 config items, three bash variables. Let's say they are $XLOCKMODE, $XLOCKOPTIONS and $XLOCKPASSWORD (this is not a real example!).

Now, Barry's way seems to be to create three files /etc/xlockmode, /etc/xlockoptions and /etc/xlockpassword and store each item one per file as a string, with no trailing LF. This means (a) the config files can't have any comments in them (b) they can't use any actual shell commands in them (c) they each only hold one variable, so the next version that needs say $XLOCKCOLOUR needs yet another file.

My suggestion: create a file, for example /etc/xlock.conf (perhaps /etc/sysconfig/xlock.conf if you want to keep these sorts of system-wide config things in one standard place). That file can look like this

Code: Select all

# /etc/sysconfig/xlock.conf -- systemwide xlock config file

# XLOCKMODE is the xlock mode number between 0 and 1599
# A common useful value is 1234
XLOCKMODE=1234

# XLOCKOPTIONS is a string with a list of options to be passed to
#   the xlock command line
XLOCKOPTIONS="-mousemotion -grabserver -whatever"

# XLOCKPASSWORD is a default pw for xlock... security risk
#   Please do not use this unless you read the manual first and
#   fully understand the implications.
XLOCKPASSWORD=""
To use the info in this file, the script needs to just do one line

Code: Select all

. /etc/sysconfig/xlock.conf
Compare that with at least 3 to read in each of the files in Barry's approach. Writing back changed values in a script that handles configuration can do something like

Code: Select all

writeconfig() {
# Usage: writeconfig(mode, options, pw)
cp -p /etc/sysconfig/xlock.conf /etc/sysconfig/xlock.old
sed -e 's/^XLOCKMODE=.*$/XLOCKMODE="$1"/ \
      -e 's/^XLOCKOPTIONS=.*$/XLOCKMODE="$2"/ \
      -e 's/^XLOCKPASSWORD=.*$/XLOCKMODE="$3"/ \
     /etc/sysconfig/xlock.old >/etc/sysconfig/xlock.conf
}
Which retains any comment lines in the config file, but updates the assignments. A more complex function could replace comments ahead of variables it changes, ... how complex you get is up to you! Actually we could look at creating a generic writeconfig function that takes a filename and list of var names as parameters, and then several shell apps could reuse the same code, if we want to get a bit fancy with this...

There are other possible approaches to the writeconfig function of course, especially if it has many (say 20 or 100) variables in it for a more complex script/application, but you get the general idea. Use one config file per app, make it contain shell code (or Perl or Tcl or whatever scripting language your app is written in!), and use it by sourcing the config file.

Not entirely incidentally, this approach is trivially modifiable to have a system wide config file that is read first, followed by a per-user one that can override the system defaults, of course. Just do something like

Code: Select all

. /etc/sysconfig/xlock.conf
[ -f ~/.xlock.conf ] && . ~/.xlock.conf
and now the app has per-user configurability at almost zero extra cost.

This is both clearer and more flexible than what is currently being done, IMO. It's also close to what you'll find under /etc/sysconfig/ on a Fedora Core system, for example. So it is in line with common practice.

Jonathan

PS. If you need a really small config file, omit the comments:

Code: Select all

XLOCKMODE=1234
XLOCKOPTIONS="-mousemotion -grabserver -whatever"
XLOCKPASSWORD=""
This is still clearer and easier to work with than three separate files, in my view.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#17 Post by BarryK »

Jonathan,
You are quite right of course, it is more efficient.
I have often thought that I should rework the entire system with just one master config file.

User avatar
jmarsden
Posts: 265
Joined: Sat 31 Dec 2005, 22:18
Location: California, USA

#18 Post by jmarsden »

BarryK wrote:You are quite right of course, it is more efficient.
I have often thought that I should rework the entire system with just one master config file.
I'm not sure if you are 100% serious here? :-) One master file gets a bit too like the infamous "Windows Registry" -- one minor editing mistake or buggy config editing tool, and the whole thing crumbles (add an extra unwanted backquote ` near the top of such a file and see what happens, for example)! One file per app is perhaps a reasonable compromise between what we seem to have now (one file per variable) and the Windows approach (one complicated database per system).

Further, we can (I think -- as yet untested under Puppy!) also use ~/.Xresources to store config items for many X apps that already know about this approach, including rxvt. Our X startup scripts (~/.xinitrc in particular) currently use it (use xrdb to merge in its content)... but we don't seem to actually do anything useful with it. Actually the scripts already include the kind of per-user override of a global systemwide config I mentioned.

I think the way ahead regarding the scripts that now use one file per variable could be to rework them one at a time, as they are enhanced for other reasons, to use something closer to what I suggested. This helps minimize the "huge flood of bugs" problem if you attempt a "big bang" change to many pieces at once, too.

Can we at least agree and document that, in general, new scripts written for Puppy should, if possible, use one config file per application rather than one file per variable? Exceptions to be negotiated with Barry on a case-by-case basis, if there are genuine reasons for needing one file per variable! Is that reasonable as a next step?

You could also consider farming out the rework effort for existing scripts among a group of developers, rather than trying to do it all yourself. If (say) ten people each took on reworking one script, we'd have ten developers with initimate useful and current knowledge of these system level scripts, which is at least a start towards your delegating parts of the development and ongoing maintenance workload to a team surrounding you. If you agree, I'll volunteer to be one of the ten developers concerned :-)

Jonathan

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#19 Post by GuestToo »

my dotpup installer uses 1 file per variable

i made a deliberate choice to do it that way ... i could have used a single configuration file but i think that in this case, 1 file per variable is simpler and more efficient ... i like simple and efficient ... and there is less potential for bugs

i don't particularly like edicts from on high, and i don't particularly like the idea that i must go cap in hand to Barry or jmarsden to have each and every detail of any contributions to Puppy i might be able to make vetted and blessed

sane and rational standards, that hopefully make sense, are one thing ... arbitrary decrees are another

User avatar
jmarsden
Posts: 265
Joined: Sat 31 Dec 2005, 22:18
Location: California, USA

#20 Post by jmarsden »

GuestToo wrote:sane and rational standards, that hopefully make sense, are one thing ... arbitrary decrees are another
I agree 100%! Arbitrary is bad. Use of existing common knowledge and standard practices is good, unless there are overwhelming reasons to go against them in a particular special situation.

So let's first ensure all parties to the discussion are informed. I recommend that you start by reading a little of the relevant literature in this field, preferably including at least Knuths classic "The Art of Programming" http://www.amazon.com/gp/product/0201485419 and Eric Raymond's more idosyncratic but much more Unix/Linux focused "The Art of Unix Programming" http://www.faqs.org/docs/artu/ . Beyond that, we could consider adding Kernigan and Pike's "The Practice of Programming" http://www.amazon.com/gp/product/020161586X/ but the first two will probably be enough to start with.

If cost of the books is a problem, at least we can all read ESR's one, because it is freely available online. He is also quite specific on this issue of design of run control files, see http://www.faqs.org/docs/artu/ch10s03.html in particular. If you lack time, perhaps just reading Chapter 10 or even just Section 3 of Chapter 10 would help, though I think the wider overall perspective gained from reading the rest of the book would be valuable (to you, to Barry, and indeed to anyone programming for Puppy Linux). Like much of ESR's writing, it is opinionated but generally well-reasoned. In my view, it's perfectly fine to disagree with his ideas, as long as you can convince yourself you have thought about the issues in depth and that your own reasoning is stronger than his.

Of course, if there is other well regarded literature in this field that supports other positions, including your own, that you think would help this discussion, do please let me know, and I'll gladly read it, so that we start from a useful common understanding of what the current thinking of the experts in this field really is.

With that sort of basic background research behind us, we will then be in a position to knowledgeably debate the relative merits of deliberately disregarding more that three decades of the accumulated wisdom of many many very intelligent and very experienced people, in favour of your own proposed approach.

I'll end this post by quoting http://www.faqs.org/docs/artu/ch10s07.html in its entirety, because it seems very relevant to your position:
The Art of Unix Programming wrote:On Breaking These Rules

The conventions described in this chapter are not absolute, but violating them will increase friction costs for users and developers in the future. Break them if you must

Post Reply