enforce screensaver for all users of a system?

Matt Morgan minxmertzmomo at gmail.com
Tue Dec 14 23:07:44 UTC 2004


On Tue, 14 Dec 2004 16:03:15 -0600, Ed Wilts <ewilts at ewilts.org> wrote:
> On Tue, Dec 14, 2004 at 04:41:13PM -0500, Matt Morgan wrote:
> > We're migrating some of our users to FC3 from Windows (yay!). In
> > Windows, we use system policies to force password-protected
> > screensavers to turn on after a certain amount of idle time.
> >
> > We can't figure out an obvious way to do this with xscreensaver. The
> > man page explains,
> >
> > "Options  to  xscreensaver  are  stored  in  one  of  two  places: in
> > a .xscreensaver file in your  home  directory;  or  in  the  X
> > resource database.  If the .xscreensaver file exists, it overrides any
> > settings in the resource database."
> >
> > In other words, you can set this up system-wide, but users can
> > override it with their own settings. I can think of obfuscatory ways
> > to prevent that most of the time (break xscreensaver-demo), and
> > reactive ways to keep it from happening for long (startup scripts that
> > delete user settings). But we can't figure out the *right* way to do
> > it. Any advice?
> 
> Without thinking about it too hard, I'd create my own system-wide
> .xscreensaver file.  Then, at user creation time, create a symlink to
> the system version and make the symlink owned by root with no user write
> access.  I obviously haven't tested this to prove that it works without
> breaking anything either.

Thanks! I tried this and there's something I'm not getting. This all
works except that when I run chmod on the symlink, nothing happens.
That is, if as root I run

chmod 644 ~morganm/.xscreensaver

chmod doesn't complain, but nothing happens to the permissions on the
symlink (which remain lrwxrwxrwx). At that point xscreensaver-demo
can't edit the file (because the actual file is 644, root.root), but
the user morganm can delete the symlink and create his own
.xscreensaver. Is that normal? Symlinks have always confused me.

For the heck of it, I tried a hard link. In that case the user can
override the permissions on the file, so that didn't work either.

Thanks,
Matt




More information about the fedora-list mailing list