Permissions on /root/
Hello, First of all, I'd like to say that, yes, I know this was discussed before, but no consensus was reached and the thread died. (Or at least, the one I found by doing a quick Google search) Back to the issue at hand, the default permissions on /root/, which, at the moment, are 755. IMHO, this is a possible security problem and it should be set to, at least, 750 (thus allowing users in the wheel group to access it). The reason behind this is simple, root is the system administrator account, it should not be used for anything but that. So, everything in /root/ is related, strictly to the task of administering the machine, thus, off limits for the average luser. A comparison between said average lusers' home dirs and /root/ isn't appropriate since, again, you should only use root for administration tasks and not for sharing files and what not, which is what (or at least, the way I understand it) why the normal users' home dirs are 755. Furthermore, I do believe the principle of least astonishment applies here. I expect root's files, in root's home, to be readable _only_ by root. Arguments against 750? A sysadmin should know what he's doing and chmod sensitive files so that nobody can read them. As a side note, while discussing this, somebody asked what's stopping you from doing a 'chmod 750 /root/'. I think the answer is that Debian shouldn't be broken, by default and rely on the system administrator to fix it. That being said, should I file a bug against base-files? P.S. Please preserve the CC: on the replies sent to the list. Thank you. -- Regards, Birzan George Cristian pgp0.pgp Description: PGP signature
Re: Permissions on /root/
On Sat, Mar 08, 2003 at 01:02:13PM +0200, Birzan George Cristian wrote: Back to the issue at hand, the default permissions on /root/, which, at the moment, are 755. IMHO, this is a possible security problem and it should be set to, at least, 750 (thus allowing users in the wheel group There is no `wheel` group in a default Debian install. You're thinking BSD. That being said, Darwin (OS X is the only BSD I have access to at the moment) does lock down /var/root to 750 root:wheel. I presume that FreeBSD (at least 4.0) does as well. comparison between said average lusers' home dirs and /root/ isn't appropriate since, again, you should only use root for administration The FHS itself does not describe root's homedir as being anything but another home directory [1]. [1] http://www.pathname.com/fhs/2.2/fhs-3.13.html It does recommend, however, that the account ONLY be used for systems administration purposes, which implies that /root falls under the purview of Systemspace. least, the way I understand it) why the normal users' home dirs are 755. Furthermore, I do believe the principle of least astonishment applies here. I expect root's files, in root's home, to be readable _only_ by root. As a slight aside: As the FHS states, it's preferable to have all system mail and whatnot going to the appropriate, unpriv'd, user, rather than into a root mailbox. Personally, I 700 /root because putting people in the root group is wrong. That's what sudo is for, after all. (This being a Linux distro, and not possessing the concept of wheel.) Muddying the distinction between Systemspace and Userspace only serves to make the system as a whole less secure and more of a pain in the butt to admin. 750 /root/'. I think the answer is that Debian shouldn't be broken, by default and rely on the system administrator to fix it. We (or rather the maintainers/developers) would first need to agree that /root is something Special and not just another homedir. I would personally agree with that assertation. It should be locked down and not touched by adduser (Would You Like To Make All Homedirs World-Readable?). -- bda Cyberpunk is dead. Long live cyberpunk. http://mirrorshades.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissions on /root/
On Sat, Mar 08, 2003 at 07:37:53AM -0500, bda wrote: It should be locked down and not touched by adduser (Would You Like To Make All Homedirs World-Readable?). Actually I'd rather not, but there are (or at least were, I've not checked in a long while) problems with apache access to /home/user/public_html if there was not global rx access to the whole directroy path string. -- -- IN MY NAME:Dale Amon, CEO/MD No Mushroom clouds over Islandone Society London and New York. www.islandone.org -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissions on /root/
On Sat, Mar 08, 2003 at 01:44:24PM +, Dale Amon wrote: On Sat, Mar 08, 2003 at 07:37:53AM -0500, bda wrote: It should be locked down and not touched by adduser (Would You Like To Make All Homedirs World-Readable?). Actually I'd rather not, but there are (or at least were, I've not checked in a long while) problems with apache access to /home/user/public_html if there was not global rx access to the whole directroy path string. Sorry, I was referring only to /root, not normal user homedirs. Unless you're thinking of http://foo.bar/~root/ for some sick reason. ;-) -- bda Cyberpunk is dead. Long live cyberpunk. http://mirrorshades.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[no subject]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 subscribe -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+agytmCMDkFhFYMcRAu/rAJ0WB3HhiLR9g6d6NdAG4cjQJ/c8zwCeMMtu syVIs5rKrSBtaoLB0k8PQUA= =hcxo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissions on /root/
Sigh. I specifically said use the original CC: and reply to the list, not reply to the list and CC:. On Sat, Mar 08, 2003 at 07:37:53AM -0500, bda wrote: On Sat, Mar 08, 2003 at 01:02:13PM +0200, Birzan George Cristian wrote: Back to the issue at hand, the default permissions on /root/, which, at the moment, are 755. IMHO, this is a possible security problem and it should be set to, at least, 750 (thus allowing users in the wheel group There is no `wheel` group in a default Debian install. You're thinking BSD. That being said, Darwin (OS X is the only BSD I have access to at the moment) does lock down /var/root to 750 root:wheel. I presume that FreeBSD (at least 4.0) does as well. Sorry, I meant the root group, which is used as the wheel group. Can't vouch for other nices since I never used any of them extensively. comparison between said average lusers' home dirs and /root/ isn't appropriate since, again, you should only use root for administration The FHS itself does not describe root's homedir as being anything but another home directory [1]. [1] http://www.pathname.com/fhs/2.2/fhs-3.13.html It does recommend, however, that the account ONLY be used for systems administration purposes, which implies that /root falls under the purview of Systemspace. least, the way I understand it) why the normal users' home dirs are 755. Furthermore, I do believe the principle of least astonishment applies here. I expect root's files, in root's home, to be readable _only_ by root. As a slight aside: As the FHS states, it's preferable to have all system mail and whatnot going to the appropriate, unpriv'd, user, rather than into a root mailbox. Personally, I 700 /root because putting people in the root group is wrong. That's what sudo is for, after all. (This being a Linux distro, and not possessing the concept of wheel.) Muddying the distinction between Systemspace and Userspace only serves to make the system as a whole less secure and more of a pain in the butt to admin. Read above, wheel is implemented, via PAM. What are these Systemspace and Userspace you're talking about? 750 /root/'. I think the answer is that Debian shouldn't be broken, by default and rely on the system administrator to fix it. We (or rather the maintainers/developers) would first need to agree that /root is something Special and not just another homedir. I would personally agree with that assertation. It should be locked down and not touched by adduser (Would You Like To Make All Homedirs World-Readable?). root is not the regular user. Users need o+x on their home dirs for Apache to be able to serve pages. -- Regards, Birzan George Cristian pgp0.pgp Description: PGP signature
Re: Permissions on /root/
Please configure your mail client to a) wrap at 80 columns and b) set In-Reply-To: On Sat, Mar 08, 2003 at 04:13:43PM +0100, I.R. van Dongen wrote: Personally, I don't beleave /root should be used for any information that is 'dangerous' I personally use it sometimes for temp storage for .debs and such, before I move them to /usr/src. Therefor I don't really care what the default permissions are for /root. the files that need to be there (for example .my.cfg) need to have permission 600 or 700. The fact that it shouldn't be used for storing any dangerous information doesn't mean it's not being used for that. What I am asking, in case my original mail wasn't clear enough, is why _shouldn't_ it be 750 or 700 by default? -- Regards, Birzan George Cristian pgp0.pgp Description: PGP signature
Re: Permissions on /root/
Birzan George Cristian wrote: First of all, I'd like to say that, yes, I know this was discussed before, but no consensus was reached and the thread died. (Or at least, the one I found by doing a quick Google search) No consensus was reached because none was possible. Back to the issue at hand, the default permissions on /root/, which, at the moment, are 755. IMHO, this is a possible security problem and it should be set to, at least, 750 (thus allowing users in the wheel group to access it). The reason behind this is simple, root is the system administrator account, it should not be used for anything but that. So, everything in /root/ is related, strictly to the task of administering the machine, thus, off limits for the average luser. But in the course of doing things that you have to do as root, when do you need to create files in /root? Almost never. If you find that you are using /root frequently, then I would guess that you are doing things as root that need not be done as root. For example, someone else in this thread says he uses /root as temporary storage for .debs, which suggests that he is running as root when he manually downloads .debs from non-apt-gettable sources. I would argue that he should download the files in his ordinary user account, then use root only to install them. In which case, obviously the files can't be in /root, because the ordinary user account can't put them there. A comparison between said average lusers' home dirs and /root/ isn't appropriate since, again, you should only use root for administration tasks and not for sharing files and what not, which is what (or at least, the way I understand it) why the normal users' home dirs are 755. A comparison between /home/* and /root fails because root shouldn't really be using his home directory for much of anything. Furthermore, I do believe the principle of least astonishment applies here. I expect root's files, in root's home, to be readable _only_ by root. Your opinion. The issue matters so little that I find neither 700 nor 755 surprising. If Debian were already setting /root to 700, that would be fine with me. But 755 is also fine. I have no particular objections to either setting. What I am responding to here is the attitude that there's something wrong with 755, and the insistence that it be changed. Arguments against 750? A sysadmin should know what he's doing and chmod sensitive files so that nobody can read them. As a side note, while discussing this, somebody asked what's stopping you from doing a 'chmod 750 /root/'. I think the answer is that Debian shouldn't be broken, by default and rely on the system administrator to fix it. It isn't broken, so that argument fails. That being said, should I file a bug against base-files? No. It'll probably just get rejected anyway. Craig pgp0.pgp Description: PGP signature
Re: Permissions on /root/
Birzan George Cristian wrote: The fact that it shouldn't be used for storing any dangerous information doesn't mean it's not being used for that. If it shouldn't be used so, but it is being used so on a particular machine, then that machine's admin is at fault. What I am asking, in case my original mail wasn't clear enough, is why _shouldn't_ it be 750 or 700 by default? No, at this point, the question is, why should it be changed? We have an established default of 755. You're asking for a change, but you have no convincing argument supporting the change. Therefore, no change. Craig pgp0.pgp Description: PGP signature
Re: Permissions on /root/
At 13:02 Uhr +0200 08.03.2003, Birzan George Cristian wrote:
the moment, are 755. IMHO, this is a possible security problem
- Why is this a possible security problem? It looks like you are
not aware that you should always and anyways (regardless of whether
you're root at the moment or not) take care to make sensitive files
not world readable. If you don't have this habit then maybe you'll
end up making sensitive files world readable in your non-root account.
- Sensitive items (like user related config files and dirs, for
example /root/.ssh/) are 0700 regardless of user, anyways, so there's
no need to add another protection.
- You should also be aware that a 0700 directory does not protect you
if you are moving another directory from outside to inside, since
users who have already chdir'd into it remain inside it. (Example:
root:anybody:
chmod 0700 /root
# root feels safe
mkdir /blah
chdir /blah
mv /blah /root
# root thinks ok now blah is safe
cd /root/blah
cat info
(enter sensitive info, Ctl-D)
cat info
(looks at info)
- The problem with a 0700 /root is that it does not leave it a *joice* anymore.
- In fact I am using /root/bin/, /root/etc/, /root/sbin/,
/root/libexec/ for scripts which I have written myself but should be
for any user on the system. My /etc/skel/.bash_profile includes
/root/bin into the user's paths.
Why do I not use /usr/local/{bin,sbin,lib} and /etc for that?
* I don't want my stuff to be mixed with software from other people.
* I want to be able to easily tar my stuff up to transfer it to
another machine.
* Sometimes I override an existing binary living in /usr/local/bin.
Since /root/bin is earlier in my path that's possible.
Maybe you can tell me which other directory is better suited for
that than /root?
I vote for leaving the permissions on /root as they are.
Christian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissions on /root/
On Sat, Mar 08, 2003 at 08:05:26AM -0800, Craig Dickson wrote: But in the course of doing things that you have to do as root, when do you need to create files in /root? Almost never. If you find that you are using /root frequently, then I would guess that you are doing things as root that need not be done as root. For example, someone else in this thread says he uses /root as temporary storage for .debs, which suggests that he is running as root when he manually downloads .debs from non-apt-gettable sources. I would argue that he should download the files in his ordinary user account, then use root only to install them. In which case, obviously the files can't be in /root, because the ordinary user account can't put them there. Yes, you don't need to have many files in there, but, IMHO, you shouldn't have to worry about users being able to look into what should be root's files. Even config files for some programs are world readable, by default. The first example that comes to mind, where you would want to have files in /root/, is when you have a script of some sort, or even a program, which should only be accessible by root. (~/bin/ is FHS compliant? I know I use it...) Your opinion. The issue matters so little that I find neither 700 nor 755 surprising. I've talked with several other friends, and most of them (5 to 1), agreed that /root/ shouldn't be 755, but something more restrictive. If Debian were already setting /root to 700, that would be fine with me. But 755 is also fine. I have no particular objections to either setting. What I am responding to here is the attitude that there's something wrong with 755, and the insistence that it be changed. Think from the perspective of the not-so-clued admin which install Debian and, even though it's mostly his fault, puts Lord knows what file in there. Shouldn't we try to prevent that? And, not only that, but you must remember that we are, after all, human. You may forget you didn't set the permissions, for example, if you deal with many systems. Shouldn't Debina try to prevent this? If the user needs/wants /root/ to be 755, he/she can do it as it'll be obvious why it's not working, as opposed to waiting for somebody to poke around your /root/ to find that out. That being said, I want to add that I'm not insisting on getting it changed, I'm just asking if there's something wrong with 750/700 that would cause it to not be the default. (I also find out if I've been doing something wrong for some time by chmodding /root/ to that. :-)) It isn't broken, so that argument fails. There are other not broken things that are being fixed, for convenience. There's one I remember offhand, the NMU against sysklogd for 'fixing' something that's easily configurable by the admin (The priority of messages that go to console). No. It'll probably just get rejected anyway. I won't submit if there's a strong opposition against my idea. Even if I do, it's not mere mortals like me who decide these kinds of things so it's a moot point. -- Regards, Birzan George Cristian pgp0.pgp Description: PGP signature
Re: Permissions on /root/
On Sat, Mar 08, 2003 at 07:12:13PM +0200, Birzan George Cristian wrote: I've talked with several other friends, and most of them (5 to 1), agreed that /root/ shouldn't be 755, but something more restrictive. I'm in agreement as well. I use /root as a common communication area among admin staff. Admin staff have their own home directories but prefer them keep them private. /root is a good place to put things which are intended to be public to the admin group. sudo is fine for doing many things, but not everything. I use cfengine2 to force it at least to 750. I also use cfengine2 to enforce all sorts of harsher preferences so that I automatically override some of the weaker debian settings within minutes of doing an apt-get or dselect upgrade. When you have multiple people, working over long periods of time (years), with varying stress conditions, there will at some point be mistakes made. That's why defense in depth is so important. The more layers of protection you can place the more likely a single mistake won't leave you wide open. -- -- IN MY NAME:Dale Amon, CEO/MD No Mushroom clouds over Islandone Society London and New York. www.islandone.org -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissions on /root/
At 19:23 Uhr +0200 08.03.2003, Birzan George Cristian wrote:
On Sat, Mar 08, 2003 at 05:40:31PM +0100, Christian Jaeger wrote:
- You should also be aware that a 0700 directory does not protect you
if you are moving another directory from outside to inside, since
users who have already chdir'd into it remain inside it.
Yes, but how often does that happen?
Maybe not often, but an attacker could run a daemon that opendir()s
each newly created directory just in the hope that one of them
happens to be moved into your secret area. Call me paranoid:) (And I
still don't see a reason why it should be different for root than
anyone else. The other user's secrets are probably just as important
as root's.)
- The problem with a 0700 /root is that it does not leave it a *joice*
anymore.
Eh, you'll have to excuse me, but I have no idea what that phrase means.
I meant, if /root is world-readable, then you can still make a
subdirectory which is not (i.e. I have a /root/tmp which is 0700). If
/root is not world-readable, then it can never contain stuff to be
used by other users.
Maybe you can tell me which other directory is better suited for
that than /root?
Yes. Your regular account's home.
I don't because:
- I'm promoting my /root/{bin,...} solution for colleagues as well,
and we share scripts in those directories. They would have to include
the bin/ subdirectory of my home dir on the machines we share.
- the scripts under /root/* are owned by root. If OTOH I'm executing
the $HOME/bin/ scripts of another user and his account is
compromised, root would be as well.
- in my own non-root ~/bin/ are scripts that are really specific to
me, noone else. (And sometimes I start writing new scripts there,
until they are ready for everyone to be used, at which point I'm
moving and chown'ing them to root.)
Christian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [work] Integrity (of Debian packages)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 08 March 2003 04:11, Pav wrote: Let me have a moment of silence for your excellent reply. Thank you, it gives me some hope again. Jord - -- Technical Consultant ECM mailto: [EMAIL PROTECTED] Key Fingerprint: 1856 A04C FB51 9D2D 09B2 58A5 96F6 37E0 1CF6 CCD0 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+ajnGlvY34Bz2zNARAmoTAJwPFYnY4sMuspUceA+zg3Ikp+qbfACdHJWw p7E2s9N1MCssLQ/Z48sxhzA= =zISU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissions on /root/
On Sat, Mar 08, 2003 at 06:09:08PM +0200, Birzan George Cristian wrote: The fact that it shouldn't be used for storing any dangerous information doesn't mean it's not being used for that. What I am asking, in case my original mail wasn't clear enough, is why _shouldn't_ it be 750 or 700 by default? Why would you want this changed but be ok with, unless I changed mine somewhere and forgot, a default root umask of 0022 ? just curious, Ted -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- WAR IS PEACE FREEDOM IS SLAVERY IGNORANCE IS STRENGTH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissions on /root/
On Sat, Mar 08, 2003 at 07:19:44PM +0100, Christian Jaeger wrote:
Call me paranoid:)
Yes, but if you're so paranoid, why not add another layer of protection,
by making /root/ 700?
I meant, if /root is world-readable, then you can still make a
subdirectory which is not (i.e. I have a /root/tmp which is 0700). If
/root is not world-readable, then it can never contain stuff to be
used by other users.
This would be the default setup, not the mandatory one. Administrators
could change it to whatever they want. As I said in a previous email,
the fact that it doesn't work is going to work is pretty obvious, as
opposed to noticing that because you were sloppy once, somebody read
something they shouldn't have.
I don't because:
- I'm promoting my /root/{bin,...} solution for colleagues as well,
and we share scripts in those directories. They would have to include
the bin/ subdirectory of my home dir on the machines we share.
- the scripts under /root/* are owned by root. If OTOH I'm executing
the $HOME/bin/ scripts of another user and his account is
compromised, root would be as well.
- in my own non-root ~/bin/ are scripts that are really specific to
me, noone else. (And sometimes I start writing new scripts there,
until they are ready for everyone to be used, at which point I'm
moving and chown'ing them to root.)
Okay, bad example. Maybe /opt/{bin,...}? Or even /opt/mystuff/{bin,...},
if you still want to be able to tar them up easily. (arguably, this
would be easily accomplished by an alias, tarstuff will tar up
/opt/{bin,...})
The least that could be done wold be to _ask_ the user which he prefers.
As I said, there are people who aren't aware of this. Others may, as I
said, get sloppy, being used to, say, RedHat, which has it 750. I'm not
saying they're not to blame, I'm just saying they should be educated.
And if all else fails, all other things being equal, I think we should
look at which of the two scenarios is more likely to occur. How many
administrators actually use the directory structure you suggested?
(which, imho, is not FHS compliant, so it can't really constitute an
argument in 755's favour...)
--
Regards,
Birzan George Cristian
pgp0.pgp
Description: PGP signature
Re: Permissions on /root/
At 17:47 Uhr + 08.03.2003, Dale Amon wrote: When you have multiple people, working over long periods of time (years), with varying stress conditions, there will at some point be mistakes made. That's why defense in depth is so important. The more layers of protection you can place the more likely a single mistake won't leave you wide open. Isn't it the same as for any user account? If that user (who maybe shares his account with other people) wants his home dir private, he can do so. Or create a subdir which is private(*). I just see no reason to make a difference between root and other users. I've started using my /root/bin/ -for-users approach since I've relied on that fact of world-readable home dirs. (Unix is socially friendly was a phrase in connection with permissions that I read somewhere when I began working with (unix/)linux.) And as written in my other reply I'm still missing a better alternative to /root/bin. /local-admin's-software/bin maybe? AFAIK, the FHS does not provide any. (*) well of course this won't help for files that have to be directly in root's home, like shell startup files (anybody ever made such a file world-writable?). But well. BTW on the solaris machine I've worked some time, root's home was /, and I'm sure that was not 0700. Christian (who is going to close this thread in his mind now :-). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissions on /root/
On Sat, 8 Mar 2003, Birzan George Cristian wrote: It should be locked down and not touched by adduser (Would You Like To Make All Homedirs World-Readable?). root is not the regular user. Users need o+x on their home dirs for Apache to be able to serve pages. No they don't. You shouldn't place user websites in their home dirs. Place the user webspace in e.g /var/www/[user] and symlink from public_html or whatever. /Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissions on /root/
On Sat, Mar 08, 2003 at 10:58:10AM -0800, Ted Parvu wrote: Why would you want this changed but be ok with, unless I changed mine somewhere and forgot, a default root umask of 0022 ? Because I haven't, yet, seen a box that came, by default, with a different umask. Again, for me it's about the principle of least astonishment... -- Regards, Birzan George Cristian pgp0.pgp Description: PGP signature
Re: Permissions on /root/
On 8 Mar 2003 at 17:40, Christian Jaeger wrote: At 13:02 Uhr +0200 08.03.2003, Birzan George Cristian wrote: - You should also be aware that a 0700 directory does not protect you if you are moving another directory from outside to inside, since users who have already chdir'd into it remain inside it. (Example: root:anybody: chmod 0700 /root # root feels safe mkdir /blah chdir /blah mv /blah /root # root thinks ok now blah is safe cd /root/blah cat info (enter sensitive info, Ctl-D) cat info (looks at info) why is he allowed to use mv /blah /root? /root is write-protected so why could he move blah inside of it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissions on /root/
Hi list, Birzan George Cristian wrote: First of all, I'd like to say that, yes, I know this was discussed before, but no consensus was reached and the thread died. (Or at least, the one I found by doing a quick Google search) No consensus was reached because none was possible. how about offering it as an installation option? * /root/ permission some say 755 because ... others 700 because ... please select [700 | 750 | 755] or whatever options seem sensible... Cheers, joost. - Support open source software like - Linux (Debian is a nice example) - Apache - PHP - MySQL - Horde and many others... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissions on /root/
[EMAIL PROTECTED] wrote: how about offering it as an installation option? * /root/ permission some say 755 because ... others 700 because ... please select [700 | 750 | 755] or whatever options seem sensible... Because it's unnecessary. Installation is already too cluttered with various choices the user has to make, most of which are more important than this one. It doesn't matter much whether /root is 755, 750, or 700. The sensible thing to do is just choose one and stick with it. The user can change it after installation if they like. Right now Debian either uses 755 or sets /root to be the same as /home/*; I'm not sure which. If you want that to change, you need a better argument than anything that has been presented so far. Craig pgp0.pgp Description: PGP signature
Re: Permissions on /root/
On Sat, Mar 08, 2003 at 08:07:51PM +0100, Christian Jaeger wrote: Isn't it the same as for any user account? If that user (who maybe shares his account with other people) wants his home dir private, he can do so. Or create a subdir which is private(*). I just see no Typical user accounts are not the same as the root user unless you go to selinux where you have to assume the admin role to actually do anything. Since I'm not running selinux on any production servers (yet) I prefer to put as severe a wall as I can between luser and root as I possibly can. The friendliness of privs depends very much on what it is you are doing. If the machine happens to be a firewall protecting a LAN with proprietary data, or a web server with many large web sites, the criteria are rather different. As I said, I use /root more as the common home for the admin group. Not necessarily security important things there all the time, but sometimes transiently there is. Security means turn everything off until the machine is totally unusable, and then turn them back on until you've got precisely what is required for the purpose and no more. Life will get easier when selinux goes more main stream as these things will be easily handled via policy rather than file owner/mode settings. -- -- IN MY NAME:Dale Amon, CEO/MD No Mushroom clouds over Islandone Society London and New York. www.islandone.org -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissions on /root/
On Sat, Mar 08, 2003 at 08:16:38PM +0100, Thomas Sj?gren wrote: root is not the regular user. Users need o+x on their home dirs for Apache to be able to serve pages. No they don't. You shouldn't place user websites in their home dirs. Place the user webspace in e.g /var/www/[user] and symlink from public_html or whatever. I sometimes do, however it complicated the back up of individuals. With rsync these days, the user backup problem on a rack of machines is pretty moot, so I'll give you that. -- -- IN MY NAME:Dale Amon, CEO/MD No Mushroom clouds over Islandone Society London and New York. www.islandone.org -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissions on /root/
At 20:23 Uhr +0100 08.03.2003, Stefan Neufeind wrote: On 8 Mar 2003 at 17:40, Christian Jaeger wrote: At 13:02 Uhr +0200 08.03.2003, Birzan George Cristian wrote: - You should also be aware that a 0700 directory does not protect you if you are moving another directory from outside to inside, since users who have already chdir'd into it remain inside it. (Example: root: anybody: - - chmod 0700 /root # root feels safe mkdir /blah chdir /blah mv /blah /root # root thinks ok now blah is safe cd /root/blah cat info (enters sensitive info, Ctl-D) cat info (looks at info) why is he allowed to use mv /blah /root? /root is write-protected so why could he move blah inside of it? It is *root* who is moving the dir. (Left side. I've increased the space a bit.) And he (is root masculine?) is moving anybody right into the secret area at the same time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
unsubscribe
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissions on /root/
Christian Jaeger [EMAIL PROTECTED] writes: I began working with (unix/)linux.) And as written in my other reply I'm still missing a better alternative to /root/bin. /local-admin's-software/bin maybe? AFAIK, the FHS does not provide any. Maybe /usr/local/sbin is, what you're looking for? Regards, Olaf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [work] Integrity of Debian packages
Hi! this is off topic, but in case you've been wondering, too: * Joost Beintema [EMAIL PROTECTED] [20030308 04:47]: Your comment seems to lay blame for 9/11 on the intelligence community. It's fair to say that they had major flaws at that time (and possibly now as well). You could argue that this specific incident could have been prevented if certain measures were in place. Keep in mind, the perpetrators were a determined group that was willing to accept death in the pursuit of their goal. That's a combination that is nearly unstoppable. All I hear is a war-yelling Bush but I haven' heared any good story (from politicians) about the WHY of attacks. economic reasons: - the oil price influences a HUGE part of the economy, having to pay the market price for iraq oil doesn't work - the bush family is a not-so-small player in weapons industry as well as oil industry - deficit/military/government spending is good for the economy (any economist can tell you that) .. the formula: GDP = C+G+I+X-Im (where: GDP == Gross Domestic Product C == Consumption G == Government spending I == Investments X == Exports Im == Imports) .. this very formular also explains tax cuts, the deficit, the hype against foreign products / Imports, etc. - military spending: Irak:~ 20.0% of GDP USA: ~ 5.5% of GDP (!) Germany: ~ 3.5% of GDP .. reasoning goes that a raise of spending for weapons beyond a general percentage is a precursor for war - as it has always been the actual values don't seem to matter much - the fact that the US just have a _huge_ GDP does count a lot .. $400 _billion_ military expenses a year are 'only' 5.5% .. the ~$26 billion offered to turkey are interesting, too. far more interesting are the ~$15 _million_ for post-war refugee help (UNHCR). another question: how could iraq to something decent using its money, considering the sanctions and the interweavement of countries these times? - old ammunition and weapon technologies have to be -uh- put out of service political reasons: - gaining access to he iraq oil fields would lessen the influence of OPEC, thus the oil price - solving the palaestina/israel conflict would compromise israel - disrupting europe unity means keeping relative strength pyschological reasons: - giving in to europe would mean losing face - admiting one was wrong would mean losing face - searching problems everywhere else but at home is far easier than facing reality - powerlessness (e.g. regarding 9/11) of oneself usually results in applying power to others .. just guessing. I'm pretty sure there are more in each category. Count -- Andreas Kotes - ICQ: 3741366 - The views expressed herein are (only) mine. Unser Leben ist das, wozu unser Denken es macht. -- OpenPGP key 0x8F94C228 Our Life is what our thinking makes it.. Your mind is a weapon! Arm it .. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [VERY Offtopic] Politics (was Debian Package Integrity)
control over members of his Branch Davidian followers, as Saddam Hussein does over the Iraqis. The parallel does not stop there. Law enforcement authorities were certain Koresh had accumulated a formidable arsenal of weapons and ammunition at his compound and may have been planning on using them someday. The FBI also had evidence that he was sexually abusing young girls in the cult. After the first law enforcement assault failed, after losing the element of surprise, the Branch Davidian compound was contained and steadily increasing pressure was applied for weeks. But then the FBI decided it could wait no longer and mounted the second assault with disastrous consequences. The children we sought to liberate all died when Koresh and his followers set fires leading to their mass death and destruction. The FBI, of course, cannot be blamed for what Koresh set in motion. Nevertheless, we learned some lessons from this unfortunate episode and quickly explored better ways to deal with such challenges. As a direct result of that exploration, many subsequent criminal/terrorist standoffs in which the FBI has been involved have been resolved peacefully and effectively. I would suggest that present circumstances vis-a-vis Iraq are very analagous, and that you consider sharing with senior administration officials the important lessons learned by the FBI at Waco. You are only too well aware that fighting the war on terrorism and crime is an unbelievably difficult mission that will only become more difficult in the years to come, adversely affecting future generations of Americans. The extraneous pressures currently being brought to bear by politicians of both parties upon the FBI and other U.S. intelligence agencies, however, only worsen the present situation. I know that my comments appear so presumptuous for a person of my rank in the organization and I'm very sorry for that impression. A word of explanation is therefore probably in order as to why I feel moved to write you directly about these issues. A good part of the reason lies in a promise I made to myself after I realized the enormity of what resulted when FBI Headquarters Supervisory personnel dismissed the warnings of Minneapolis agents pre-September 11, 2001. I was well aware of the forceful but frustrated efforts being made by Minneapolis case agents and their supervisor in their efforts to get Headquarters to move. But since my own role was peripheral, I did not think I could be of much additional help. Since that fateful day of September 11, 2001, however, I have not ceased to regret that perhaps I did not do all that I might have done. I promised myself that in the future I would always try. I appreciate that you alone do not determine policy on the terrorist threat from inside or outside the country, that, indeed, you may have little influence in the crafting of broad domestic or foreign policy. And it seems clear to me now that the decision to attack Iraq was taken some time ago and you, even as FBI Director, may be little more than a helpless bystander. Such an attack, though, may have grave consequences for your ability to discharge your responsibility to protect Americans, and it is altogether likely that you will find yourself a helpless bystander to a rash of 9-11s. The bottom line is this: We should be deluding neither ourselves nor the American people that there is any way the FBI, despite the various improvements you are implementing, will be able to stem the flood of terrorism that will likely head our way in the wake of an attack on Iraq. What troubles me most is that I have no assurance that you have made that clear to the president. If you believe my concerns have merit, I would ask you to share them with the president and attorney general. We no doubt can agree that our Government has a gargantuan task facing it of melding American foreign policy to make the world, and primarily United States soil, a safer place. I pray for our American and allied world leaders^Ò success in achieving this most important objective. Thank you so much for allowing me to express these thoughts. They are personal in nature and should not be construed as representing the view of any FBI unit or other agents. Yours truly, Coleen Rowley On Sun, 9 Mar 2003, Andreas Kotes wrote: Hi! this is off topic, but in case you've been wondering, too: * Joost Beintema [EMAIL PROTECTED] [20030308 04:47]: Your comment seems to lay blame for 9/11 on the intelligence community. It's fair to say that they had major flaws at that time (and possibly now as well). You could argue that this specific incident could have been prevented if certain measures were in place. Keep in mind, the perpetrators were a determined group that was willing to accept death in the pursuit of their goal. That's a combination that is nearly unstoppable. All I hear is a war-yelling Bush but I haven' heared any good story (from politicians) about the WHY of attacks
Re: [VERY Offtopic] Politics (was Debian Package Integrity)
On Sat, Mar 08, 2003 at 06:18:13PM -0600, David Ehle wrote: Ok I've resisted this thread for quite a while because its so off topic... but since nobody is complaining... I'm going to post a facinating letter from inside the FBI I ran across recently. I havn't done much work checking authenticity but even its bogus it makes some great points. Please! I've read her thing before. It's real and has been in the news. Some agree with her and some don't, and it is very much on party lines. I read plenty of this elsewhere, which is where this discussion should be taken. alt.conspiracy, I don't much care, but not here. If you want my opinions, you'll have read them elsewhere: http://www.samizdata.com/blog where I am an editor. Now *please* get back to debian security. -- -- IN MY NAME:Dale Amon, CEO/MD No Mushroom clouds over Islandone Society London and New York. www.islandone.org -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissions on /root/
At 23:29 Uhr +0100 08.03.2003, Olaf Dietsche wrote:
Christian Jaeger [EMAIL PROTECTED] writes:
I began working with (unix/)linux.) And as written in my other reply
I'm still missing a better alternative to
/root/bin. /local-admin's-software/bin maybe? AFAIK, the FHS does
not provide any.
Maybe /usr/local/sbin is, what you're looking for?
No, this is still a directory generally used for local tar.gz
installs. And sbin is for admins, bin for users, right?.
(The suggestion to use /opt/* is ok. It's (as I've just realized)
even what the FHS stipulates: the directories /opt/bin, /opt/doc,
/opt/include, /opt/info, /opt/lib, and /opt/man are reserved for
local system administrator use. Hmm, Debian does not create any of
the /opt (and /opt/{bin,doc,include,info,lib,man}), /var/opt, and
/etc/opt directories in it's standard installation, and does not even
mention those in the policy (chapter 10.1). I'll maybe have to set up
cfengine to create those.. ;-).)
Christian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissions on /root/
Christian Jaeger [EMAIL PROTECTED] writes: At 23:29 Uhr +0100 08.03.2003, Olaf Dietsche wrote: Christian Jaeger [EMAIL PROTECTED] writes: I began working with (unix/)linux.) And as written in my other reply I'm still missing a better alternative to /root/bin. /local-admin's-software/bin maybe? AFAIK, the FHS does not provide any. Maybe /usr/local/sbin is, what you're looking for? No, this is still a directory generally used for local tar.gz installs. And sbin is for admins, bin for users, right?. Yup, I misinterpreted, what you mean with /local-admin's-software/bin. Regards, Olaf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [VERY Offtopic] Politics (was Debian Package Integrity)
On Sun, Mar 09, 2003 at 02:30:11AM +0100, Thomas Ritter wrote: Am Sonntag, 9. M?rz 2003 01:52 schrieb Dale Amon: http://www.samizdata.com/blog Oops. http://www.samizdata.net/blog -- -- IN MY NAME:Dale Amon, CEO/MD No Mushroom clouds over Islandone Society London and New York. www.islandone.org -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [VERY Offtopic] Politics (was Debian Package Integrity)
On Saturday 08 March 2003 7:52 pm, Dale Amon wrote: Now *please* get back to debian security. Concur...wholeheartedly! Jeff Elkins http://www.elkins.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Permissions on /root/
Hello, First of all, I'd like to say that, yes, I know this was discussed before, but no consensus was reached and the thread died. (Or at least, the one I found by doing a quick Google search) Back to the issue at hand, the default permissions on /root/, which, at the moment, are 755. IMHO, this is a possible security problem and it should be set to, at least, 750 (thus allowing users in the wheel group to access it). The reason behind this is simple, root is the system administrator account, it should not be used for anything but that. So, everything in /root/ is related, strictly to the task of administering the machine, thus, off limits for the average luser. A comparison between said average lusers' home dirs and /root/ isn't appropriate since, again, you should only use root for administration tasks and not for sharing files and what not, which is what (or at least, the way I understand it) why the normal users' home dirs are 755. Furthermore, I do believe the principle of least astonishment applies here. I expect root's files, in root's home, to be readable _only_ by root. Arguments against 750? A sysadmin should know what he's doing and chmod sensitive files so that nobody can read them. As a side note, while discussing this, somebody asked what's stopping you from doing a 'chmod 750 /root/'. I think the answer is that Debian shouldn't be broken, by default and rely on the system administrator to fix it. That being said, should I file a bug against base-files? P.S. Please preserve the CC: on the replies sent to the list. Thank you. -- Regards, Birzan George Cristian pgpju4JezEChb.pgp Description: PGP signature
Re: Permissions on /root/
On Sat, Mar 08, 2003 at 01:02:13PM +0200, Birzan George Cristian wrote: Back to the issue at hand, the default permissions on /root/, which, at the moment, are 755. IMHO, this is a possible security problem and it should be set to, at least, 750 (thus allowing users in the wheel group There is no `wheel` group in a default Debian install. You're thinking BSD. That being said, Darwin (OS X is the only BSD I have access to at the moment) does lock down /var/root to 750 root:wheel. I presume that FreeBSD (at least 4.0) does as well. comparison between said average lusers' home dirs and /root/ isn't appropriate since, again, you should only use root for administration The FHS itself does not describe root's homedir as being anything but another home directory [1]. [1] http://www.pathname.com/fhs/2.2/fhs-3.13.html It does recommend, however, that the account ONLY be used for systems administration purposes, which implies that /root falls under the purview of Systemspace. least, the way I understand it) why the normal users' home dirs are 755. Furthermore, I do believe the principle of least astonishment applies here. I expect root's files, in root's home, to be readable _only_ by root. As a slight aside: As the FHS states, it's preferable to have all system mail and whatnot going to the appropriate, unpriv'd, user, rather than into a root mailbox. Personally, I 700 /root because putting people in the root group is wrong. That's what sudo is for, after all. (This being a Linux distro, and not possessing the concept of wheel.) Muddying the distinction between Systemspace and Userspace only serves to make the system as a whole less secure and more of a pain in the butt to admin. 750 /root/'. I think the answer is that Debian shouldn't be broken, by default and rely on the system administrator to fix it. We (or rather the maintainers/developers) would first need to agree that /root is something Special and not just another homedir. I would personally agree with that assertation. It should be locked down and not touched by adduser (Would You Like To Make All Homedirs World-Readable?). -- bda Cyberpunk is dead. Long live cyberpunk. http://mirrorshades.org
Re: Permissions on /root/
On Sat, Mar 08, 2003 at 07:37:53AM -0500, bda wrote: It should be locked down and not touched by adduser (Would You Like To Make All Homedirs World-Readable?). Actually I'd rather not, but there are (or at least were, I've not checked in a long while) problems with apache access to /home/user/public_html if there was not global rx access to the whole directroy path string. -- -- IN MY NAME:Dale Amon, CEO/MD No Mushroom clouds over Islandone Society London and New York. www.islandone.org --
Re: Permissions on /root/
On Sat, Mar 08, 2003 at 01:44:24PM +, Dale Amon wrote: On Sat, Mar 08, 2003 at 07:37:53AM -0500, bda wrote: It should be locked down and not touched by adduser (Would You Like To Make All Homedirs World-Readable?). Actually I'd rather not, but there are (or at least were, I've not checked in a long while) problems with apache access to /home/user/public_html if there was not global rx access to the whole directroy path string. Sorry, I was referring only to /root, not normal user homedirs. Unless you're thinking of http://foo.bar/~root/ for some sick reason. ;-) -- bda Cyberpunk is dead. Long live cyberpunk. http://mirrorshades.org
Re: Re: Permissions on /root/
Personally, I don't beleave /root should be used for any information that is 'dangerous' I personally use it sometimes for temp storage for .debs and such, before I move them to /usr/src. Therefor I don't really care what the default permissions are for /root. the files that need to be there (for example .my.cfg) need to have permission 600 or 700. Gr, Ivo van Dongen On Sat, 8 Mar 2003 09:34:37 -0500, [EMAIL PROTECTED] wrote: On Sat, Mar 08, 2003 at 01:44:24PM +, Dale Amon wrote: On Sat, Mar 08, 2003 at 07:37:53AM -0500, bda wrote: It should be locked down and not touched by adduser (Would You Like To Make All Homedirs World-Readable?). Actually I'd rather not, but there are (or at least were, I've not checked in a long while) problems with apache access to /home/user/public_html if there was not global rx access to the whole directroy path string. Sorry, I was referring only to /root, not normal user homedirs. Unless you're thinking of http://foo.bar/~root/ for some sick reason. ;-) -- bda Cyberpunk is dead. Long live cyberpunk. http://mirrorshades.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[no subject]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 subscribe -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+agytmCMDkFhFYMcRAu/rAJ0WB3HhiLR9g6d6NdAG4cjQJ/c8zwCeMMtu syVIs5rKrSBtaoLB0k8PQUA= =hcxo -END PGP SIGNATURE-
Re: Permissions on /root/
Sigh. I specifically said use the original CC: and reply to the list, not reply to the list and CC:. On Sat, Mar 08, 2003 at 07:37:53AM -0500, bda wrote: On Sat, Mar 08, 2003 at 01:02:13PM +0200, Birzan George Cristian wrote: Back to the issue at hand, the default permissions on /root/, which, at the moment, are 755. IMHO, this is a possible security problem and it should be set to, at least, 750 (thus allowing users in the wheel group There is no `wheel` group in a default Debian install. You're thinking BSD. That being said, Darwin (OS X is the only BSD I have access to at the moment) does lock down /var/root to 750 root:wheel. I presume that FreeBSD (at least 4.0) does as well. Sorry, I meant the root group, which is used as the wheel group. Can't vouch for other nices since I never used any of them extensively. comparison between said average lusers' home dirs and /root/ isn't appropriate since, again, you should only use root for administration The FHS itself does not describe root's homedir as being anything but another home directory [1]. [1] http://www.pathname.com/fhs/2.2/fhs-3.13.html It does recommend, however, that the account ONLY be used for systems administration purposes, which implies that /root falls under the purview of Systemspace. least, the way I understand it) why the normal users' home dirs are 755. Furthermore, I do believe the principle of least astonishment applies here. I expect root's files, in root's home, to be readable _only_ by root. As a slight aside: As the FHS states, it's preferable to have all system mail and whatnot going to the appropriate, unpriv'd, user, rather than into a root mailbox. Personally, I 700 /root because putting people in the root group is wrong. That's what sudo is for, after all. (This being a Linux distro, and not possessing the concept of wheel.) Muddying the distinction between Systemspace and Userspace only serves to make the system as a whole less secure and more of a pain in the butt to admin. Read above, wheel is implemented, via PAM. What are these Systemspace and Userspace you're talking about? 750 /root/'. I think the answer is that Debian shouldn't be broken, by default and rely on the system administrator to fix it. We (or rather the maintainers/developers) would first need to agree that /root is something Special and not just another homedir. I would personally agree with that assertation. It should be locked down and not touched by adduser (Would You Like To Make All Homedirs World-Readable?). root is not the regular user. Users need o+x on their home dirs for Apache to be able to serve pages. -- Regards, Birzan George Cristian pgpc5imCpkvn0.pgp Description: PGP signature
Re: Permissions on /root/
Please configure your mail client to a) wrap at 80 columns and b) set In-Reply-To: On Sat, Mar 08, 2003 at 04:13:43PM +0100, I.R. van Dongen wrote: Personally, I don't beleave /root should be used for any information that is 'dangerous' I personally use it sometimes for temp storage for .debs and such, before I move them to /usr/src. Therefor I don't really care what the default permissions are for /root. the files that need to be there (for example .my.cfg) need to have permission 600 or 700. The fact that it shouldn't be used for storing any dangerous information doesn't mean it's not being used for that. What I am asking, in case my original mail wasn't clear enough, is why _shouldn't_ it be 750 or 700 by default? -- Regards, Birzan George Cristian pgpCb9a4naU56.pgp Description: PGP signature
Re: Permissions on /root/
Birzan George Cristian wrote: First of all, I'd like to say that, yes, I know this was discussed before, but no consensus was reached and the thread died. (Or at least, the one I found by doing a quick Google search) No consensus was reached because none was possible. Back to the issue at hand, the default permissions on /root/, which, at the moment, are 755. IMHO, this is a possible security problem and it should be set to, at least, 750 (thus allowing users in the wheel group to access it). The reason behind this is simple, root is the system administrator account, it should not be used for anything but that. So, everything in /root/ is related, strictly to the task of administering the machine, thus, off limits for the average luser. But in the course of doing things that you have to do as root, when do you need to create files in /root? Almost never. If you find that you are using /root frequently, then I would guess that you are doing things as root that need not be done as root. For example, someone else in this thread says he uses /root as temporary storage for .debs, which suggests that he is running as root when he manually downloads .debs from non-apt-gettable sources. I would argue that he should download the files in his ordinary user account, then use root only to install them. In which case, obviously the files can't be in /root, because the ordinary user account can't put them there. A comparison between said average lusers' home dirs and /root/ isn't appropriate since, again, you should only use root for administration tasks and not for sharing files and what not, which is what (or at least, the way I understand it) why the normal users' home dirs are 755. A comparison between /home/* and /root fails because root shouldn't really be using his home directory for much of anything. Furthermore, I do believe the principle of least astonishment applies here. I expect root's files, in root's home, to be readable _only_ by root. Your opinion. The issue matters so little that I find neither 700 nor 755 surprising. If Debian were already setting /root to 700, that would be fine with me. But 755 is also fine. I have no particular objections to either setting. What I am responding to here is the attitude that there's something wrong with 755, and the insistence that it be changed. Arguments against 750? A sysadmin should know what he's doing and chmod sensitive files so that nobody can read them. As a side note, while discussing this, somebody asked what's stopping you from doing a 'chmod 750 /root/'. I think the answer is that Debian shouldn't be broken, by default and rely on the system administrator to fix it. It isn't broken, so that argument fails. That being said, should I file a bug against base-files? No. It'll probably just get rejected anyway. Craig pgp56WMDHKPGC.pgp Description: PGP signature
Re: Permissions on /root/
Birzan George Cristian wrote: The fact that it shouldn't be used for storing any dangerous information doesn't mean it's not being used for that. If it shouldn't be used so, but it is being used so on a particular machine, then that machine's admin is at fault. What I am asking, in case my original mail wasn't clear enough, is why _shouldn't_ it be 750 or 700 by default? No, at this point, the question is, why should it be changed? We have an established default of 755. You're asking for a change, but you have no convincing argument supporting the change. Therefore, no change. Craig pgps6oPxOMWsc.pgp Description: PGP signature
Re: Permissions on /root/
At 13:02 Uhr +0200 08.03.2003, Birzan George Cristian wrote:
the moment, are 755. IMHO, this is a possible security problem
- Why is this a possible security problem? It looks like you are
not aware that you should always and anyways (regardless of whether
you're root at the moment or not) take care to make sensitive files
not world readable. If you don't have this habit then maybe you'll
end up making sensitive files world readable in your non-root account.
- Sensitive items (like user related config files and dirs, for
example /root/.ssh/) are 0700 regardless of user, anyways, so there's
no need to add another protection.
- You should also be aware that a 0700 directory does not protect you
if you are moving another directory from outside to inside, since
users who have already chdir'd into it remain inside it. (Example:
root:anybody:
chmod 0700 /root
# root feels safe
mkdir /blah
chdir /blah
mv /blah /root
# root thinks ok now blah is safe
cd /root/blah
cat info
(enter sensitive info, Ctl-D)
cat info
(looks at info)
- The problem with a 0700 /root is that it does not leave it a *joice* anymore.
- In fact I am using /root/bin/, /root/etc/, /root/sbin/,
/root/libexec/ for scripts which I have written myself but should be
for any user on the system. My /etc/skel/.bash_profile includes
/root/bin into the user's paths.
Why do I not use /usr/local/{bin,sbin,lib} and /etc for that?
* I don't want my stuff to be mixed with software from other people.
* I want to be able to easily tar my stuff up to transfer it to
another machine.
* Sometimes I override an existing binary living in /usr/local/bin.
Since /root/bin is earlier in my path that's possible.
Maybe you can tell me which other directory is better suited for
that than /root?
I vote for leaving the permissions on /root as they are.
Christian.
Re: Permissions on /root/
On Sat, Mar 08, 2003 at 08:05:26AM -0800, Craig Dickson wrote: But in the course of doing things that you have to do as root, when do you need to create files in /root? Almost never. If you find that you are using /root frequently, then I would guess that you are doing things as root that need not be done as root. For example, someone else in this thread says he uses /root as temporary storage for .debs, which suggests that he is running as root when he manually downloads .debs from non-apt-gettable sources. I would argue that he should download the files in his ordinary user account, then use root only to install them. In which case, obviously the files can't be in /root, because the ordinary user account can't put them there. Yes, you don't need to have many files in there, but, IMHO, you shouldn't have to worry about users being able to look into what should be root's files. Even config files for some programs are world readable, by default. The first example that comes to mind, where you would want to have files in /root/, is when you have a script of some sort, or even a program, which should only be accessible by root. (~/bin/ is FHS compliant? I know I use it...) Your opinion. The issue matters so little that I find neither 700 nor 755 surprising. I've talked with several other friends, and most of them (5 to 1), agreed that /root/ shouldn't be 755, but something more restrictive. If Debian were already setting /root to 700, that would be fine with me. But 755 is also fine. I have no particular objections to either setting. What I am responding to here is the attitude that there's something wrong with 755, and the insistence that it be changed. Think from the perspective of the not-so-clued admin which install Debian and, even though it's mostly his fault, puts Lord knows what file in there. Shouldn't we try to prevent that? And, not only that, but you must remember that we are, after all, human. You may forget you didn't set the permissions, for example, if you deal with many systems. Shouldn't Debina try to prevent this? If the user needs/wants /root/ to be 755, he/she can do it as it'll be obvious why it's not working, as opposed to waiting for somebody to poke around your /root/ to find that out. That being said, I want to add that I'm not insisting on getting it changed, I'm just asking if there's something wrong with 750/700 that would cause it to not be the default. (I also find out if I've been doing something wrong for some time by chmodding /root/ to that. :-)) It isn't broken, so that argument fails. There are other not broken things that are being fixed, for convenience. There's one I remember offhand, the NMU against sysklogd for 'fixing' something that's easily configurable by the admin (The priority of messages that go to console). No. It'll probably just get rejected anyway. I won't submit if there's a strong opposition against my idea. Even if I do, it's not mere mortals like me who decide these kinds of things so it's a moot point. -- Regards, Birzan George Cristian pgpbls0OMLyli.pgp Description: PGP signature
Re: Permissions on /root/
On Sat, Mar 08, 2003 at 05:40:31PM +0100, Christian Jaeger wrote:
- You should also be aware that a 0700 directory does not protect you
if you are moving another directory from outside to inside, since
users who have already chdir'd into it remain inside it.
Yes, but how often does that happen? And, don't get me wrong, I'm not
promoting blind faith in the permissions, I'm just saying I think it
would be a Good Thing. My former reply, the one to Craig Dickson,
explained not only why, but also replied to some of your other points.
- The problem with a 0700 /root is that it does not leave it a *joice*
anymore.
Eh, you'll have to excuse me, but I have no idea what that phrase means.
- In fact I am using /root/bin/, /root/etc/, /root/sbin/,
/root/libexec/ for scripts which I have written myself but should be
for any user on the system. My /etc/skel/.bash_profile includes
/root/bin into the user's paths.
Why do I not use /usr/local/{bin,sbin,lib} and /etc for that?
* I don't want my stuff to be mixed with software from other people.
* I want to be able to easily tar my stuff up to transfer it to
another machine.
* Sometimes I override an existing binary living in /usr/local/bin.
Since /root/bin is earlier in my path that's possible.
Maybe you can tell me which other directory is better suited for
that than /root?
Yes. Your regular account's home.
--
Regards,
Birzan George Cristian
pgpMOzxJAgQJt.pgp
Description: PGP signature
Re: Permissions on /root/
On Sat, Mar 08, 2003 at 07:12:13PM +0200, Birzan George Cristian wrote: I've talked with several other friends, and most of them (5 to 1), agreed that /root/ shouldn't be 755, but something more restrictive. I'm in agreement as well. I use /root as a common communication area among admin staff. Admin staff have their own home directories but prefer them keep them private. /root is a good place to put things which are intended to be public to the admin group. sudo is fine for doing many things, but not everything. I use cfengine2 to force it at least to 750. I also use cfengine2 to enforce all sorts of harsher preferences so that I automatically override some of the weaker debian settings within minutes of doing an apt-get or dselect upgrade. When you have multiple people, working over long periods of time (years), with varying stress conditions, there will at some point be mistakes made. That's why defense in depth is so important. The more layers of protection you can place the more likely a single mistake won't leave you wide open. -- -- IN MY NAME:Dale Amon, CEO/MD No Mushroom clouds over Islandone Society London and New York. www.islandone.org --
Re: [work] Integrity (of Debian packages)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 08 March 2003 04:11, Pav wrote: Let me have a moment of silence for your excellent reply. Thank you, it gives me some hope again. Jord - -- Technical Consultant ECM mailto: [EMAIL PROTECTED] Key Fingerprint: 1856 A04C FB51 9D2D 09B2 58A5 96F6 37E0 1CF6 CCD0 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+ajnGlvY34Bz2zNARAmoTAJwPFYnY4sMuspUceA+zg3Ikp+qbfACdHJWw p7E2s9N1MCssLQ/Z48sxhzA= =zISU -END PGP SIGNATURE-
Re: Permissions on /root/
On Sat, Mar 08, 2003 at 06:09:08PM +0200, Birzan George Cristian wrote: The fact that it shouldn't be used for storing any dangerous information doesn't mean it's not being used for that. What I am asking, in case my original mail wasn't clear enough, is why _shouldn't_ it be 750 or 700 by default? Why would you want this changed but be ok with, unless I changed mine somewhere and forgot, a default root umask of 0022 ? just curious, Ted -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- WAR IS PEACE FREEDOM IS SLAVERY IGNORANCE IS STRENGTH
Re: Permissions on /root/
On Sat, Mar 08, 2003 at 07:19:44PM +0100, Christian Jaeger wrote:
Call me paranoid:)
Yes, but if you're so paranoid, why not add another layer of protection,
by making /root/ 700?
I meant, if /root is world-readable, then you can still make a
subdirectory which is not (i.e. I have a /root/tmp which is 0700). If
/root is not world-readable, then it can never contain stuff to be
used by other users.
This would be the default setup, not the mandatory one. Administrators
could change it to whatever they want. As I said in a previous email,
the fact that it doesn't work is going to work is pretty obvious, as
opposed to noticing that because you were sloppy once, somebody read
something they shouldn't have.
I don't because:
- I'm promoting my /root/{bin,...} solution for colleagues as well,
and we share scripts in those directories. They would have to include
the bin/ subdirectory of my home dir on the machines we share.
- the scripts under /root/* are owned by root. If OTOH I'm executing
the $HOME/bin/ scripts of another user and his account is
compromised, root would be as well.
- in my own non-root ~/bin/ are scripts that are really specific to
me, noone else. (And sometimes I start writing new scripts there,
until they are ready for everyone to be used, at which point I'm
moving and chown'ing them to root.)
Okay, bad example. Maybe /opt/{bin,...}? Or even /opt/mystuff/{bin,...},
if you still want to be able to tar them up easily. (arguably, this
would be easily accomplished by an alias, tarstuff will tar up
/opt/{bin,...})
The least that could be done wold be to _ask_ the user which he prefers.
As I said, there are people who aren't aware of this. Others may, as I
said, get sloppy, being used to, say, RedHat, which has it 750. I'm not
saying they're not to blame, I'm just saying they should be educated.
And if all else fails, all other things being equal, I think we should
look at which of the two scenarios is more likely to occur. How many
administrators actually use the directory structure you suggested?
(which, imho, is not FHS compliant, so it can't really constitute an
argument in 755's favour...)
--
Regards,
Birzan George Cristian
pgp4502loiZ6Q.pgp
Description: PGP signature
Re: Permissions on /root/
At 17:47 Uhr + 08.03.2003, Dale Amon wrote: When you have multiple people, working over long periods of time (years), with varying stress conditions, there will at some point be mistakes made. That's why defense in depth is so important. The more layers of protection you can place the more likely a single mistake won't leave you wide open. Isn't it the same as for any user account? If that user (who maybe shares his account with other people) wants his home dir private, he can do so. Or create a subdir which is private(*). I just see no reason to make a difference between root and other users. I've started using my /root/bin/ -for-users approach since I've relied on that fact of world-readable home dirs. (Unix is socially friendly was a phrase in connection with permissions that I read somewhere when I began working with (unix/)linux.) And as written in my other reply I'm still missing a better alternative to /root/bin. /local-admin's-software/bin maybe? AFAIK, the FHS does not provide any. (*) well of course this won't help for files that have to be directly in root's home, like shell startup files (anybody ever made such a file world-writable?). But well. BTW on the solaris machine I've worked some time, root's home was /, and I'm sure that was not 0700. Christian (who is going to close this thread in his mind now :-).
Re: Permissions on /root/
On Sat, 8 Mar 2003, Birzan George Cristian wrote: It should be locked down and not touched by adduser (Would You Like To Make All Homedirs World-Readable?). root is not the regular user. Users need o+x on their home dirs for Apache to be able to serve pages. No they don't. You shouldn't place user websites in their home dirs. Place the user webspace in e.g /var/www/[user] and symlink from public_html or whatever. /Thomas
Re: Permissions on /root/
On Sat, Mar 08, 2003 at 10:58:10AM -0800, Ted Parvu wrote: Why would you want this changed but be ok with, unless I changed mine somewhere and forgot, a default root umask of 0022 ? Because I haven't, yet, seen a box that came, by default, with a different umask. Again, for me it's about the principle of least astonishment... -- Regards, Birzan George Cristian pgp0ABBDzqMgX.pgp Description: PGP signature
Re: Permissions on /root/
On 8 Mar 2003 at 17:40, Christian Jaeger wrote: At 13:02 Uhr +0200 08.03.2003, Birzan George Cristian wrote: - You should also be aware that a 0700 directory does not protect you if you are moving another directory from outside to inside, since users who have already chdir'd into it remain inside it. (Example: root:anybody: chmod 0700 /root # root feels safe mkdir /blah chdir /blah mv /blah /root # root thinks ok now blah is safe cd /root/blah cat info (enter sensitive info, Ctl-D) cat info (looks at info) why is he allowed to use mv /blah /root? /root is write-protected so why could he move blah inside of it?
Re: Permissions on /root/
[EMAIL PROTECTED] wrote: how about offering it as an installation option? * /root/ permission some say 755 because ... others 700 because ... please select [700 | 750 | 755] or whatever options seem sensible... Because it's unnecessary. Installation is already too cluttered with various choices the user has to make, most of which are more important than this one. It doesn't matter much whether /root is 755, 750, or 700. The sensible thing to do is just choose one and stick with it. The user can change it after installation if they like. Right now Debian either uses 755 or sets /root to be the same as /home/*; I'm not sure which. If you want that to change, you need a better argument than anything that has been presented so far. Craig pgpJh8c8s9Q0y.pgp Description: PGP signature
Re: Permissions on /root/
On Sat, Mar 08, 2003 at 08:07:51PM +0100, Christian Jaeger wrote: Isn't it the same as for any user account? If that user (who maybe shares his account with other people) wants his home dir private, he can do so. Or create a subdir which is private(*). I just see no Typical user accounts are not the same as the root user unless you go to selinux where you have to assume the admin role to actually do anything. Since I'm not running selinux on any production servers (yet) I prefer to put as severe a wall as I can between luser and root as I possibly can. The friendliness of privs depends very much on what it is you are doing. If the machine happens to be a firewall protecting a LAN with proprietary data, or a web server with many large web sites, the criteria are rather different. As I said, I use /root more as the common home for the admin group. Not necessarily security important things there all the time, but sometimes transiently there is. Security means turn everything off until the machine is totally unusable, and then turn them back on until you've got precisely what is required for the purpose and no more. Life will get easier when selinux goes more main stream as these things will be easily handled via policy rather than file owner/mode settings. -- -- IN MY NAME:Dale Amon, CEO/MD No Mushroom clouds over Islandone Society London and New York. www.islandone.org --
Re: Permissions on /root/
On Sat, Mar 08, 2003 at 08:16:38PM +0100, Thomas Sj?gren wrote: root is not the regular user. Users need o+x on their home dirs for Apache to be able to serve pages. No they don't. You shouldn't place user websites in their home dirs. Place the user webspace in e.g /var/www/[user] and symlink from public_html or whatever. I sometimes do, however it complicated the back up of individuals. With rsync these days, the user backup problem on a rack of machines is pretty moot, so I'll give you that. -- -- IN MY NAME:Dale Amon, CEO/MD No Mushroom clouds over Islandone Society London and New York. www.islandone.org --
Re: Permissions on /root/
At 20:23 Uhr +0100 08.03.2003, Stefan Neufeind wrote: On 8 Mar 2003 at 17:40, Christian Jaeger wrote: At 13:02 Uhr +0200 08.03.2003, Birzan George Cristian wrote: - You should also be aware that a 0700 directory does not protect you if you are moving another directory from outside to inside, since users who have already chdir'd into it remain inside it. (Example: root: anybody: - - chmod 0700 /root # root feels safe mkdir /blah chdir /blah mv /blah /root # root thinks ok now blah is safe cd /root/blah cat info (enters sensitive info, Ctl-D) cat info (looks at info) why is he allowed to use mv /blah /root? /root is write-protected so why could he move blah inside of it? It is *root* who is moving the dir. (Left side. I've increased the space a bit.) And he (is root masculine?) is moving anybody right into the secret area at the same time.
unsubscribe
Re: Permissions on /root/
Christian Jaeger [EMAIL PROTECTED] writes: I began working with (unix/)linux.) And as written in my other reply I'm still missing a better alternative to /root/bin. /local-admin's-software/bin maybe? AFAIK, the FHS does not provide any. Maybe /usr/local/sbin is, what you're looking for? Regards, Olaf.
Re: [work] Integrity of Debian packages
Hi! this is off topic, but in case you've been wondering, too: * Joost Beintema [EMAIL PROTECTED] [20030308 04:47]: Your comment seems to lay blame for 9/11 on the intelligence community. It's fair to say that they had major flaws at that time (and possibly now as well). You could argue that this specific incident could have been prevented if certain measures were in place. Keep in mind, the perpetrators were a determined group that was willing to accept death in the pursuit of their goal. That's a combination that is nearly unstoppable. All I hear is a war-yelling Bush but I haven' heared any good story (from politicians) about the WHY of attacks. economic reasons: - the oil price influences a HUGE part of the economy, having to pay the market price for iraq oil doesn't work - the bush family is a not-so-small player in weapons industry as well as oil industry - deficit/military/government spending is good for the economy (any economist can tell you that) .. the formula: GDP = C+G+I+X-Im (where: GDP == Gross Domestic Product C == Consumption G == Government spending I == Investments X == Exports Im == Imports) .. this very formular also explains tax cuts, the deficit, the hype against foreign products / Imports, etc. - military spending: Irak:~ 20.0% of GDP USA: ~ 5.5% of GDP (!) Germany: ~ 3.5% of GDP .. reasoning goes that a raise of spending for weapons beyond a general percentage is a precursor for war - as it has always been the actual values don't seem to matter much - the fact that the US just have a _huge_ GDP does count a lot .. $400 _billion_ military expenses a year are 'only' 5.5% .. the ~$26 billion offered to turkey are interesting, too. far more interesting are the ~$15 _million_ for post-war refugee help (UNHCR). another question: how could iraq to something decent using its money, considering the sanctions and the interweavement of countries these times? - old ammunition and weapon technologies have to be -uh- put out of service political reasons: - gaining access to he iraq oil fields would lessen the influence of OPEC, thus the oil price - solving the palaestina/israel conflict would compromise israel - disrupting europe unity means keeping relative strength pyschological reasons: - giving in to europe would mean losing face - admiting one was wrong would mean losing face - searching problems everywhere else but at home is far easier than facing reality - powerlessness (e.g. regarding 9/11) of oneself usually results in applying power to others .. just guessing. I'm pretty sure there are more in each category. Count -- Andreas Kotes - ICQ: 3741366 - The views expressed herein are (only) mine. Unser Leben ist das, wozu unser Denken es macht. -- OpenPGP key 0x8F94C228 Our Life is what our thinking makes it.. Your mind is a weapon! Arm it ..
Re: [VERY Offtopic] Politics (was Debian Package Integrity)
control over members of his Branch Davidian followers, as Saddam Hussein does over the Iraqis. The parallel does not stop there. Law enforcement authorities were certain Koresh had accumulated a formidable arsenal of weapons and ammunition at his compound and may have been planning on using them someday. The FBI also had evidence that he was sexually abusing young girls in the cult. After the first law enforcement assault failed, after losing the element of surprise, the Branch Davidian compound was contained and steadily increasing pressure was applied for weeks. But then the FBI decided it could wait no longer and mounted the second assault with disastrous consequences. The children we sought to liberate all died when Koresh and his followers set fires leading to their mass death and destruction. The FBI, of course, cannot be blamed for what Koresh set in motion. Nevertheless, we learned some lessons from this unfortunate episode and quickly explored better ways to deal with such challenges. As a direct result of that exploration, many subsequent criminal/terrorist standoffs in which the FBI has been involved have been resolved peacefully and effectively. I would suggest that present circumstances vis-a-vis Iraq are very analagous, and that you consider sharing with senior administration officials the important lessons learned by the FBI at Waco. You are only too well aware that fighting the war on terrorism and crime is an unbelievably difficult mission that will only become more difficult in the years to come, adversely affecting future generations of Americans. The extraneous pressures currently being brought to bear by politicians of both parties upon the FBI and other U.S. intelligence agencies, however, only worsen the present situation. I know that my comments appear so presumptuous for a person of my rank in the organization and I'm very sorry for that impression. A word of explanation is therefore probably in order as to why I feel moved to write you directly about these issues. A good part of the reason lies in a promise I made to myself after I realized the enormity of what resulted when FBI Headquarters Supervisory personnel dismissed the warnings of Minneapolis agents pre-September 11, 2001. I was well aware of the forceful but frustrated efforts being made by Minneapolis case agents and their supervisor in their efforts to get Headquarters to move. But since my own role was peripheral, I did not think I could be of much additional help. Since that fateful day of September 11, 2001, however, I have not ceased to regret that perhaps I did not do all that I might have done. I promised myself that in the future I would always try. I appreciate that you alone do not determine policy on the terrorist threat from inside or outside the country, that, indeed, you may have little influence in the crafting of broad domestic or foreign policy. And it seems clear to me now that the decision to attack Iraq was taken some time ago and you, even as FBI Director, may be little more than a helpless bystander. Such an attack, though, may have grave consequences for your ability to discharge your responsibility to protect Americans, and it is altogether likely that you will find yourself a helpless bystander to a rash of 9-11s. The bottom line is this: We should be deluding neither ourselves nor the American people that there is any way the FBI, despite the various improvements you are implementing, will be able to stem the flood of terrorism that will likely head our way in the wake of an attack on Iraq. What troubles me most is that I have no assurance that you have made that clear to the president. If you believe my concerns have merit, I would ask you to share them with the president and attorney general. We no doubt can agree that our Government has a gargantuan task facing it of melding American foreign policy to make the world, and primarily United States soil, a safer place. I pray for our American and allied world leaders^Ò success in achieving this most important objective. Thank you so much for allowing me to express these thoughts. They are personal in nature and should not be construed as representing the view of any FBI unit or other agents. Yours truly, Coleen Rowley On Sun, 9 Mar 2003, Andreas Kotes wrote: Hi! this is off topic, but in case you've been wondering, too: * Joost Beintema [EMAIL PROTECTED] [20030308 04:47]: Your comment seems to lay blame for 9/11 on the intelligence community. It's fair to say that they had major flaws at that time (and possibly now as well). You could argue that this specific incident could have been prevented if certain measures were in place. Keep in mind, the perpetrators were a determined group that was willing to accept death in the pursuit of their goal. That's a combination that is nearly unstoppable. All I hear is a war-yelling Bush but I haven' heared any good story (from politicians) about the WHY of attacks
Re: [VERY Offtopic] Politics (was Debian Package Integrity)
On Sat, Mar 08, 2003 at 06:18:13PM -0600, David Ehle wrote: Ok I've resisted this thread for quite a while because its so off topic... but since nobody is complaining... I'm going to post a facinating letter from inside the FBI I ran across recently. I havn't done much work checking authenticity but even its bogus it makes some great points. Please! I've read her thing before. It's real and has been in the news. Some agree with her and some don't, and it is very much on party lines. I read plenty of this elsewhere, which is where this discussion should be taken. alt.conspiracy, I don't much care, but not here. If you want my opinions, you'll have read them elsewhere: http://www.samizdata.com/blog where I am an editor. Now *please* get back to debian security. -- -- IN MY NAME:Dale Amon, CEO/MD No Mushroom clouds over Islandone Society London and New York. www.islandone.org --
Re: Permissions on /root/
At 23:29 Uhr +0100 08.03.2003, Olaf Dietsche wrote:
Christian Jaeger [EMAIL PROTECTED] writes:
I began working with (unix/)linux.) And as written in my other reply
I'm still missing a better alternative to
/root/bin. /local-admin's-software/bin maybe? AFAIK, the FHS does
not provide any.
Maybe /usr/local/sbin is, what you're looking for?
No, this is still a directory generally used for local tar.gz
installs. And sbin is for admins, bin for users, right?.
(The suggestion to use /opt/* is ok. It's (as I've just realized)
even what the FHS stipulates: the directories /opt/bin, /opt/doc,
/opt/include, /opt/info, /opt/lib, and /opt/man are reserved for
local system administrator use. Hmm, Debian does not create any of
the /opt (and /opt/{bin,doc,include,info,lib,man}), /var/opt, and
/etc/opt directories in it's standard installation, and does not even
mention those in the policy (chapter 10.1). I'll maybe have to set up
cfengine to create those.. ;-).)
Christian.
Re: Permissions on /root/
Christian Jaeger [EMAIL PROTECTED] writes: At 23:29 Uhr +0100 08.03.2003, Olaf Dietsche wrote: Christian Jaeger [EMAIL PROTECTED] writes: I began working with (unix/)linux.) And as written in my other reply I'm still missing a better alternative to /root/bin. /local-admin's-software/bin maybe? AFAIK, the FHS does not provide any. Maybe /usr/local/sbin is, what you're looking for? No, this is still a directory generally used for local tar.gz installs. And sbin is for admins, bin for users, right?. Yup, I misinterpreted, what you mean with /local-admin's-software/bin. Regards, Olaf.
Re: [VERY Offtopic] Politics (was Debian Package Integrity)
On Sun, Mar 09, 2003 at 02:30:11AM +0100, Thomas Ritter wrote: Am Sonntag, 9. M?rz 2003 01:52 schrieb Dale Amon: http://www.samizdata.com/blog Oops. http://www.samizdata.net/blog -- -- IN MY NAME:Dale Amon, CEO/MD No Mushroom clouds over Islandone Society London and New York. www.islandone.org --
