Date: Wed, 5 Dec 2007 10:37:50 -0500
From: "Douglas A. Tutty" <dtutty@porchlight.ca>
To: debian-user@lists.debian.org
Subject: Re: Preferred Backup Method?
Message-ID: <20071205153750.GK6480@titan.hooton>
Content-Type: multipart/mixed; boundary="+QahgC5+KEYLbs62"
Content-Disposition: inline
--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Tue, Dec 04, 2007 at 05:19:48PM -0500, Michael Pobega wrote:
> Just `tar -cvvf backup-`date`.tar /`? Is it really that simple?
You don't need to backup the whole /.
I have a file called backuplist:
/etc/
/usr/local/
/root/
/var/local/
/home/
and I have a file called excludelist:
/var/local/backup
/var/local/unbackedup
/home/dtutty/uldl
/root/uldl
These are both in /usr/local/lib/backup, although they should go in
/etc/ but I wanted to avoid any conflicts with any package I may install
that would have /etc/backup/.
For completeness, here's my whole backup script. This is for my main
box titan. Less complex scripts are run on other boxes. Other scrips
do the rsync. Note that my /home is on a cat lvm while my system
(including /var/local where the backups go) is on lvm over raid1.
Doug.
--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=titan-backup
#!/bin/bash
### special to hostname titan
# Backup to /var/local/backup/titan
# backing up directories listed in /usr/local/lib/backup/list
# and excluding those in /usr/local/lib/backup/excludelist
/bin/echo -e "System Backup"
/bin/echo -e "=============\n"
/bin/echo -e "First: ensure users have saved essential stuff to ~/essential_backup,"
/bin/echo -e "either as sym-links or actual files; backup will dump links as files."
/bin/echo -e "Examples may be: exporting bookmarks list, special docs, etc."
/bin/echo -e "Backup will then save those to a separate file before"
/bin/echo -e "running the main backup program.\n"
/bin/echo -e "\nBackup files will be in /var/local/backup/titan/"
/bin/echo -e "and will be done in order of priority to restoring the system."
/bin/echo -e "These can then be copied to media-of-choice.\a\n"
/bin/echo -e "\nBackup takes around 10 minutes.\n"
read -p "Press <enter> when ready to continue backup"
/bin/echo -en "\nSaving grub menu.lst..."
/bin/cp -af /boot/grub/menu.lst /var/local/backup/titan
/bin/echo -e "Done."
/bin/echo -en "\nSaving necessary /etc/files plain text..."
## note: bare-bones recovery from basedebs.tar.gz doesn't have bzip2
## so with entire /etc/ backed up bzip2, need everything that we'
## need prior to and for connecting to the internet available
## in either plain text or gzip.
mkdir -m 0750 /var/local/backup/titan/etc
chown root.adm /var/local/backup/titan/etc
/bin/cp -af /etc/fstab /var/local/backup/titan/etc
/bin/cp -af /etc/modules /var/local/backup/titan/etc
/bin/cp -af /etc/hosts /var/local/backup/titan/etc
/bin/cp -af /etc/hosts.allow /var/local/backup/titan/etc
/bin/cp -af /etc/hosts.deny /var/local/backup/titan/etc
/bin/cp -af /etc/inittab /var/local/backup/titan/etc
/bin/cp -af /etc/network/interfaces /var/local/backup/titan/etc
/bin/cp -af /etc/hostname /var/local/backup/titan/etc
/bin/cp -af /etc/modutils/ /var/local/backup/titan/etc/
/bin/rm -rf /var/local/backup/titan/etc/modutils/arch
/bin/cp -af /etc/modprobe.d/ /var/local/backup/titan/etc/
/bin/cp -af /etc/resolv.conf /var/local/backup/titan/etc
/bin/cp -af /etc/ppp/ /var/local/backup/titan/etc/
/bin/cp -af /etc/chatscripts/ /var/local/backup/titan/etc/
/bin/echo -e "Done."
/bin/echo -en "\nSaving the partition table and disk usage information..."
/sbin/fdisk -lu /dev/sda > /var/local/backup/titan/sda_partitions
/sbin/sfdisk -d /dev/sda > /var/local/backup/titan/sda_sfdisk.out
/sbin/fdisk -lu /dev/sdb > /var/local/backup/titan/sdb_partitions
/sbin/sfdisk -d /dev/sdb > /var/local/backup/titan/sdb_sfdisk.out
du -c --si --max-depth=1 /* > /var/local/backup/titan/dusummary 2>/dev/null
df --si > /var/local/backup/titan/dfsummary
/bin/echo -e "Done."
/bin/echo "Saving package selection..."
dpkg --get-selections > /var/local/backup/titan/inst_deb.sel
aptitude search '~i!~M' > /var/local/backup/titan/apt_inst.sel
/bin/echo "Done."
/bin/echo -e "Backing up /root/service/ to /var/local/backup/titan"
/bin/cp -af /root/service/ /var/local/backup/titan/
/bin/echo "Saving etc.tgz.bak"
/bin/cp -af /var/local/backup/titan/etc.tgz /var/local/backup/titan/etc.tgz.bak
/bin/echo -e "Backing up /etc/ to /var/local/backup/titan/etc.tgz"
/bin/tar -czf /var/local/backup/titan/etc.tgz /etc/
/bin/echo -e "Done."
/bin/echo "Removing saved etc.tgz.bak"
/bin/rm -f /var/local/backup/titan/etc.tgz.bak
/bin/echo "Done."
/bin/echo "Saving es_bk.tgz.bak"
/bin/cp -af /var/local/backup/titan/es_bk.tgz /var/local/backup/titan/es_bk.tgz.bak
/bin/echo -e "\nBacking up /var/local/essential_backup/ >"
/bin/echo -en " /var/local/backup/titan/es_bk.tgz"
/bin/tar -czhPf /var/local/backup/titan/es_bk.tgz /var/local/essential_backup/
# c=create, -h=don't dump symlinks, but files pointed to
# P=ablsolute path name so they go back exactly where they belong
/bin/echo -e "Done"
/bin/echo "Removing saved es_bk.tgz.bak"
/bin/rm -f /var/local/backup/titan/es_bk.tgz.bak
/bin/echo "Done."
#/bin/echo "Saving backup.tgz.bak"
#/bin/cp -af /var/local/backup/titan/backup.tgz /var/local/backup/titan/backup.tgz.bak
#/bin/echo -e "Backing-up complete system: > /var/local/backup/titan/backup.tgz"
#/bin/tar -czf /var/local/backup/titan/backup.tgz -T /usr/local/lib/backup/backuplist -X /usr/local/lib/backup/excludelist
#/bin/echo "Removing saved backup.tgz.bak"
#/bin/rm -f /var/local/backup/titan/backup.tgz.bak
#/bin/echo "Done."
/bin/echo -e "Backing-up complete system: > /var/local/backup/titan/backup.tgz.XX"
/bin/rm -f /var/local/backup/titan/backup.t*
/bin/tar -cz -T /usr/local/lib/backup/backuplist -X /usr/local/lib/backup/excludelist | split -b 600m - /var/local/backup/titan/backup.tgz.
/bin/echo "Done."
/bin/echo "Saving uldl.tgz.bak"
/bin/cp -af /var/local/backup/titan/uldl.tgz /var/local/backup/titan/uldl.tgz.bak
/bin/echo -e "Backing up /home/dtutty/uldl > /var/local/backup/titan/uldl.tgz"
/bin/tar -czf /var/local/backup/titan/uldl.tgz /home/dtutty/uldl/
/bin/echo "Removing saved uldl.tgz.bak"
/bin/rm -f /var/local/backup/titan/uldl.tgz.bak
/bin/echo "Done."
/bin/echo "Changing oweners and permissions of /var/local/backup/titan"
/bin/chown -R root.adm /var/local/backup/titan/*
/bin/chmod -R o-rwx /var/local/backup/titan/*
/bin/chmod -R g+rw /var/local/backup/titan/*
/bin/echo "Done."
/bin/sync
/bin/echo -e "\nBackup finished.\n"
/bin/echo -e "Remember to copy to floppy."
# vim: tw=0 :
--+QahgC5+KEYLbs62--
Date: Wed, 5 Dec 2007 09:52:09 -0500
From: "Douglas A. Tutty" <dtutty@porchlight.ca>
To: debian-user@lists.debian.org
Subject: Re: Preferred Backup Method?
Message-ID: <20071205145209.GD6480@titan.hooton>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Tue, Dec 04, 2007 at 03:22:48PM -0800, David Brodbeck wrote:
> What's your experience with rdiff-backup been? When I tried it I
> found it way too fragile to be a viable backup solution. If the
> backup was interrupted for any reason, it would corrupt the history
> data, and all future backup or restore attempts in that directory
> would cause rdiff-backup to crash. Also, it had the usual Python
> error recovery problems -- whenever an error occurred the actual
> error message was buried somewhere in a gargantuan stack trace.
Please don't call this the "Usual Python error recovery problems".
Python allows you to trap all the errors it could discover. You just
have to wrap everything in a try block. So if you're getting error
messages in a stack trace, then call it a bug.
Date: Wed, 5 Dec 2007 10:08:07 -0500
From: "Douglas A. Tutty" <dtutty@porchlight.ca>
To: debian-user@lists.debian.org
Subject: Re: Restore menus after FS problem
Message-ID: <20071205150807.GH6480@titan.hooton>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Tue, Dec 04, 2007 at 05:32:36PM -0500, David Bruce wrote:
> After a power outage triggering the need for fsck on several partitions, it
> appears the KDE menus got hosed - many entries no longer have a command
> associated with them, specifically all of the KDE apps. I can't find any
> other evidence of data problems. Is there any simple way to recreate the menu
> entries? I think I could uninstall KDE and reinstall, but that seems
> too "brute force".
Before you worry about menus, consider if anything else was broken. Is
it a KDE problem, or a problem in your home directory. If you create a
new user, can you create menu items? If so, reinstalling KDE won't help
since the problem is in your own home directory. Look for signs of
anything else missing.
Doug.
Date: Wed, 5 Dec 2007 10:14:19 -0500
From: "Douglas A. Tutty" <dtutty@porchlight.ca>
To: debian-user@lists.debian.org
Subject: Re: random keystrokes ignored on console
Message-ID: <20071205151419.GI6480@titan.hooton>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Tue, Dec 04, 2007 at 07:51:30PM -0600, Owen Heisler wrote:
> On Sat, 2007.12.01 20:33, Douglas A. Tutty wrote:
> > On Thu, Nov 29, 2007 at 09:32:52PM -0600, Owen Heisler wrote:
> > > Sometimes, when I type in the console, about 40% of the keystrokes are ignored.
> > > If I type (for example) "startx" and hit enter, I'll see "sart" or somesuch and
> > > the command fails. In that same case, typing "sttartxx" and enter probably
> > > would have worked, with "startx" being run. The enter key is also affected, so
> > > maybe I'd have had to hit it twice. This is frustrating, obviously. This
> > > - does not seem to be related to system temperature,
> > > - does not happen in X,
> > > - doesn't seem to be happening consistently,
> > > - and affects logging in (username & password) too.
> > >
> > > This is on a new ThinkPad running Debian Lenny/Sid amd64. I thought this
> > > problem could be hardware-related, so I ran the hardware tests available on the
> > > Rescue & Recovery disc included with the laptop. Two tests failed:
> > > System Board: USB Port Test - Abnormal Exit
> > > SMBIOS: Standards Test - Failed
> > > but they don't seem related to the problem.
> > How did you determine that the hardware errors reported don't seem to be
> > related to the problem? Get the service manual from IBM's website and
> > see what it says to do to fix the problem. Do the diags give you any
> > FRU (Field-Replacable Unit) numbers?
>
> I don't know whether the hardware errors are related, but I'm beginning to not
> trust the PCDoctor software included on the ThinkPad Rescue & Recovery media.
> It doesn't include any more information than what is in this message (unless
> I'm missing something). Linux isn't complaining about any hardware and
> everything seems to work.
I know that some IBMs come with nice software for user's to run, but
usually there's a bios-based advanced diagnostics. If you get the
service manual from IBM's website, you'll probably find the magic
keystrokes (try holding down F1 while you power on) to get into the
advanced diagnostics. If there is a hardware fault, it will give you
an FRU number which you then look up in the service manual and it tells
you what it is and what to do. Its usally quite detailed.
Doug.
Date: Wed, 5 Dec 2007 09:39:54 -0500
From: "Douglas A. Tutty" <dtutty@porchlight.ca>
To: debian-user@lists.debian.org
Subject: Re: permissions in /sbin
Message-ID: <20071205143954.GB6480@titan.hooton>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Wed, Dec 05, 2007 at 07:51:55AM -0600, John Hasler wrote:
> andy writes:
> > OK - but according to RUTE sbin = "Superuser binary executables.
>
> The "s" is for "system", not for "superuser".
>
> > These are programs for system administration only. Only the root will
> > have these executables in their path" ("Rute User's Tutorial &
> > Exposition", Paul Sheer, 2002; p137).
>
> Any user can add /sbin to her path.
On some Unix's, the "s" stands for "staticlly-linked" as in they don't
rely on /lib so you can fix a system if the linker isn't working. This
doesn't apply to debian.
Doug.
Date: Wed, 5 Dec 2007 09:50:11 -0500
From: "Douglas A. Tutty" <dtutty@porchlight.ca>
To: debian-user@lists.debian.org
Subject: Re: Preferred Backup Method?
Message-ID: <20071205145011.GC6480@titan.hooton>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Tue, Dec 04, 2007 at 04:22:42PM -0600, Ron Johnson wrote:
> On 12/04/07 16:01, Douglas A. Tutty wrote:
> [snip]
> >
> > less frequent burn to tiny CD-R to fit in the Bank's Safety Deposit Box.
> >
> > Before I go away anywhere (i.e. out of town), I copy the most important
> > of the backup to a 4 GB USB stick.
> >
> > This means that I have a separate directory called "essential_backup"
> > with a symlink in each user's home directory. They are to place a
> > symlink of any critical data in that directory. That directory is
> > tarred up (following the symlinks) very frequently indeed and propogated
> > to the other box immediatly.
> >
> > The regular stuff is tarred up (tgz) and split to 650 MB size e.g.
> > backup.tgz.aa to fit on CD-Rs.
>
> That's good for personal use (I do something similar, but send it
> off to an external drive), but not adequate for a server.
After that backup.tbz is made, I rsync it to another box. Its the main
box that has the burner.
>
> > If security of the backups is required (other than physical security of
> > the media), then I use openssl to encrypt it with an unencrypted README
> > file, with the commands used to encrypt and decrypt (minus the actual
> > password), included on each backup media.
>
> How do you do that? (I'd have uses gpg.)
>
Just doing a quick look around, gpg is bigger and needs some setup, also
isn't available easily or by default on as many systems.
OpenSSL is dead simple if you've go the binary. Eg: lets say you want
to encrypt with blowfish:
openssl bf -a -e -salt -in file -out file.bf
It prompts for passphrase
To decrypt:
openssl bf -a -d -salt in file.bf -out file
Date: Wed, 5 Dec 2007 16:26:38 +0100
From: Misko <adatrg-mlist@yahoo.com.au>
To: debian-user@lists.debian.org
Subject: Re: Can not read some messages with signature in mutt
Message-ID: <20071205152638.GA3702@alfa.qvirt.zxc>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Tue, Dec 04, 2007 at 02:22:25PM -0800, Andrew Sackville-West wrote:
> > I'm guessing GPG is not setup on your computer. Try setting
> > crypt_verify_sig to no.
> >
> > Regards,
> > Andrei
> > P.S. Deliberately not signed to make it easier for you to read it ;)
>
> that spoils the fun... I was just thinking how hilarious it would be
> if we all replied with signed mail...
>
> okay, unsigned to just to be nice ;-P
>
> A
I putted 'set crypt_verify_sig=no' line inot .muttrc file
but it does not help. Funny thing is that I can not read emails
only from Michael Pobega. All other messages (signet or not)
are readable to me.
When I read signet message mutt says:
'PGP signature could NOT be verified.'
but show the content in pager. Only for Michael's emails it says:
'Could not copy message'
amd refuse to show the text of message. This is most confusig to me.
Just now I found new way to read Michael's emails:
first pressing 'v' to see attachment and than with enter I can
read his message. What I noticed with this process is that
Michael's messages has only one attachment:
I 1 [text/plain, 7bit, 1.3K]
but all other signed emails has two attachments:
I 1 [text/plain, quoted, us-ascii, 0.3K]
I 2 Digital signature [applica/pgp-signat, 7bit, 0.2K]
Could this be the problem? But then I am puzzled why is it only me
who can not read his messages and rest of you can.
Misko
Date: Wed, 5 Dec 2007 17:24:50 +0100
From: Nyizsnyik Ferenc <nyizsa@bluebottle.com>
To: debian-user@lists.debian.org
Subject: Re: permissions in general (WAS: Re: permissions in /sbin)
Message-ID: <20071205172450.7f0553b2@localhost.localdomain>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Wed, 5 Dec 2007 16:58:59 +0100
"Martin Marcher" <martin@marcher.name> wrote:
> Hi,
>
> jumping in.
>
> On 12/4/07, andy <geek_show@dsl.pipex.com> wrote:
> > ls -l /sbin is all
> >
> > -rwxr-xr-x 1 root root ...
>
> I understand this issue. What I don't get is why it seems to be the
> overall default that others may read and execute files in most cases.
>
> To me it would make sense to have something like (very naive right
> now, hope you get the idea):
>
> /bin root:users rwxr-x---
> /sbin root:adm rwxr-x---
> /usr/bin root:users rwxr-x---
> /usr/sbin root:adm rwxr-x---
I do get your idea, but have a look at /bin! You will find some very
important stuff there, like bash, login and cat, but many more, that
every user should be able to use.
I also get that you want to enable every user by adding r-x rights to
the users group, but there are a few "users" that are not members of
the users group, such as www-data (Apache's "user") and postgres. They
also need those binaries.
> and so on. Using acl's it would be very easy to add even more groups.
> I think the explicit adding of others would make a lot of sense and
> secure the system in a standard way.
>
> I guess it's more a historical reason that others can r+x most of the
> system but I can see a lot of benefits in denying others by default
> (of course there's a lot of work involved to migrate from the current
> permission schema that's at least a serious drawback)
>
> What do you think?
>
--
Szia:
Nyizsa.
----------------------------------------------------------------------
Get a free email address with REAL anti-spam protection.
http://www.bluebottle.com/tag/1
Date: Wed, 5 Dec 2007 11:31:17 -0500 (EST)
From: chloe K <chloekcy2000@yahoo.ca>
To: debian-user@lists.debian.org
Subject: Re: rsync to clone disk - Can it work? grub-install error
Message-ID: <675895.56907.qm@web57411.mail.re1.yahoo.com>
Content-Type: multipart/alternative; boundary="0-1231923507-1196872277=:56907"
Content-Transfer-Encoding: 7bit
--0-1231923507-1196872277=:56907
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
thank you Andrew
this is my mistake. the tmp folder is missing
grub-install is fine
thank you=20
Andrew Sackville-West <andrew@farwestbilliards.com> wrote: On Wed, Dec 05=
, 2007 at 09:43:16AM -0500, chloe K wrote:
>=20
>=20
> Andrew Sackville-West wrote: On Tue, Dec 04, 2007 at 02:56:57PM -0500,=
chloe K wrote:
> > Hi all
> >=20
> > I install etch in hda
> > then I add the hdc which have same partition but not same size in hda
> >=20
> > /dev/hda1 /boot
> > /dev/hda2 /swap
> > /dev/hda3 /
> >=20
> > i use rsync to copy data from hda to hdc
> >=20
> > I use fedora5 boot disk to boot.=20
> > mount /boot and / and chroot to /
>=20
> did you mount /boot within the chroot?=20
hmmm... what about the rest of the file system? Is / all on one
partition? What are the permissions on /tmp? and does /bin exist at
this point?
>=20
>=20
> Yes, I did
>=20
>=20
> > but I got error to grub-install /dev/hda
> >=20
> > You shouldn't call /sbin/grub-install. Please call /usr/sbin/grub-ins=
tall instead!
> > tempnam: No such file or directory
> > /usr/sbin/grub-install: line 394: $log_file: ambigous redirect
>=20
> what actual command did you enter?=20
>=20
>=20
> grub-install /dev/hda
>=20
I looked at the code and the issue is $log_file, which gets set early
on but could be changed in a number of circumstances. But they all
center around the use of /tmp and /bin/tempfile. I think somehow
you're getting a null $log_file and thus causing this ambiguous
redirect.=20
I'm not sh pro by any stretch, so ymmv.
A
=20
---------------------------------
Looking for a X-Mas gift? Everybody needs a Flickr Pro Account!
--0-1231923507-1196872277=:56907
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
thank you Andrew<br><br>this is my mistake. the tmp folder is missing<br>=
<br>grub-install is fine<br><br>thank you <br><br><b><i>Andrew Sackville-=
West <andrew@farwestbilliards.com></i></b> wrote:<blockquote class=3D=
"replbq" style=3D"border-left: 2px solid rgb(16, 16, 255); margin-left: 5=
px; padding-left: 5px;"> On Wed, Dec 05, 2007 at 09:43:16AM -0500, chloe =
K wrote:<br>> <br>> <br>> Andrew Sackville-West <andrew@farwestb=
illiards.com> wrote: On Tue, Dec 04, 2007 at 02:56:57PM -0500, chloe K wr=
ote:<br>> > Hi all<br>> > <br>> > I install etch in hda=
<br>> > then I add the hdc which have same partition but not same s=
ize in hda<br>> > <br>> > /dev/hda1 /boot<br>> > /dev/h=
da2 /swap<br>> > /dev/hda3 /<br>> > <br>> > i use rsync=
to copy data from hda to hdc<br>> > <br>> > I use fedora5 bo=
ot disk to boot. <br>> > mount /boot and / and chroot to /<br>> =
<br>> did you mount /boot within the
chroot? <br><br>hmmm... what about the rest of the file system? Is / al=
l on one<br>partition? What are the permissions on /tmp? and does /bin ex=
ist at<br>this point?<br><br>> <br>> <br>> Yes, I did<br>> <b=
r>> <br>> > but I got error to grub-install /dev/hda<br>> >=
; <br>> > You shouldn't call /sbin/grub-install. Please call /usr/s=
bin/grub-install instead!<br>> > tempnam: No such file or directory=
<br>> > /usr/sbin/grub-install: line 394: $log_file: ambigous redir=
ect<br>> <br>> what actual command did you enter? <br>> <br>>=
<br>> grub-install /dev/hda<br>> <br><br>I looked at the code and =
the issue is $log_file, which gets set early<br>on but could be changed i=
n a number of circumstances. But they all<br>center around the use of /tm=
p and /bin/tempfile. I think somehow<br>you're getting a null $log_file a=
nd thus causing this ambiguous<br>redirect. <br><br>I'm not sh pro by any=
stretch, so
ymmv.<br><br>A<br></andrew@farwestbilliards.com></blockquote><br><p> =
;
<hr size=3D1>Looking for a X-Mas gift? <a href=3D"http://www.flickr=
.com/gift/"><b> Everybody needs a Flickr Pro Account!</b></a>
--0-1231923507-1196872277=:56907--
Date: Wed, 5 Dec 2007 08:23:37 -0800
From: Mike Bird <mgb-debian@yosemite.net>
To: debian-user@lists.debian.org
Subject: Re: permissions in general (WAS: Re: permissions in /sbin)
Message-Id: <200712050823.37993.mgb-debian@yosemite.net>
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On Wednesday 05 December 2007 07:58:59 Martin Marcher wrote:
> On 12/4/07, andy <geek_show@dsl.pipex.com> wrote:
> > ls -l /sbin is all
> >
> > -rwxr-xr-x 1 root root ...
>
> I understand this issue. What I don't get is why it seems to be the
> overall default that others may read and execute files in most cases.
>
> To me it would make sense to have something like (very naive right
> now, hope you get the idea):
>
> /bin root:users rwxr-x---
> /sbin root:adm rwxr-x---
> /usr/bin root:users rwxr-x---
> /usr/sbin root:adm rwxr-x---
>
> and so on. Using acl's it would be very easy to add even more groups.
> I think the explicit adding of others would make a lot of sense and
> secure the system in a standard way.
>
> I guess it's more a historical reason that others can r+x most of the
> system but I can see a lot of benefits in denying others by default
> (of course there's a lot of work involved to migrate from the current
> permission schema that's at least a serious drawback)
There's very little value to blocking read or execute access to
executables. A user could compile or download their own
executable in their own home directory to do the same job.
Instead we control what executables can do, e.g. by limiting
which files can be read or written (by any/all executables).
--Mike Bird
Date: Wed, 5 Dec 2007 17:53:15 +0100
From: "Martin Marcher" <martin@marcher.name>
To: debian-user <debian-user@lists.debian.org>
Subject: Re: permissions in general (WAS: Re: permissions in /sbin)
Message-ID: <5fa6c12e0712050853x7f9c672v1ba718b5a666e85c@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi,
On 12/5/07, Nyizsnyik Ferenc <nyizsa@bluebottle.com> wrote:
> On Wed, 5 Dec 2007 16:58:59 +0100
> "Martin Marcher" <martin@marcher.name> wrote:
> > /bin root:users rwxr-x---
> > /sbin root:adm rwxr-x---
> > /usr/bin root:users rwxr-x---
> > /usr/sbin root:adm rwxr-x---
>
> I do get your idea, but have a look at /bin! You will find some very
> important stuff there, like bash, login and cat, but many more, that
> every user should be able to use.
If a user and or group needs to be able to access stuff from a
directory the admin should explicitely allow access. Not rely on that
users can do so anyway....
> I also get that you want to enable every user by adding r-x rights to
> the users group, but there are a few "users" that are not members of
> the users group, such as www-data (Apache's "user") and postgres. They
> also need those binaries.
While that is true I still think that the added administrational
overhead (again: explicit is better then implicit)
from man setfacl
setfacl -m g:www-data:rx /bin
wouldn't that work too?
> > and so on. Using acl's it would be very easy to add even more groups.
> > I think the explicit adding of others would make a lot of sense and
> > secure the system in a standard way.
> > I guess it's more a historical reason that others can r+x most of the
> > system but I can see a lot of benefits in denying others by default
> > (of course there's a lot of work involved to migrate from the current
> > permission schema that's at least a serious drawback)
--
http://noneisyours.marcher.name
http://feeds.feedburner.com/NoneIsYours
Date: Wed, 5 Dec 2007 17:57:13 +0100
From: "Martin Marcher" <martin@marcher.name>
To: debian-user@lists.debian.org
Subject: Re: permissions in general (WAS: Re: permissions in /sbin)
Message-ID: <5fa6c12e0712050857r6401e81cu1c2543f2a634b8b3@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On 12/5/07, Mike Bird <mgb-debian@yosemite.net> wrote:
> > I guess it's more a historical reason that others can r+x most of the
> > system but I can see a lot of benefits in denying others by default
> > (of course there's a lot of work involved to migrate from the current
> > permission schema that's at least a serious drawback)
>
> There's very little value to blocking read or execute access to
> executables. A user could compile or download their own
> executable in their own home directory to do the same job.
So the user needs to get a precompiled gcc somewhere.
Then she would need to get all the header files necessary
Then she needs to get the source.
Then the quota is full... :)
> Instead we control what executables can do, e.g. by limiting
> which files can be read or written (by any/all executables).
are you talking about Role Based access or limiting access to the
directories where a user can write to?
Why I think it's good to remove others is somewhat the same reasen as
why in a firewall ruleset the policy should be drop.
You can easily forget to lock down something but if you forget to open
it up you can be sure that within an hour users will give you a call
(or mail if they can execute the program) and complain...
--
http://noneisyours.marcher.name
http://feeds.feedburner.com/NoneIsYours
End of debian-user-digest Digest V2007 Issue #2960
**************************************************
Received on Wed Dec 5 12:16:09 2007