[gentoo-user] about permission setting for /var/tmp/portage/../work

[gentoo-user] about permission setting for /var/tmp/portage/../work

[William Xu]

Hi, why the `work' subdir under /var/tmp/.. has this sort of permission
setting: 

,----
| drwx------ 3 portage portage 80 Sep 3 10:43 work
`----

This way, it seems rather difficult for a non-root user to access
them. Currently I'm trying to debug emacs, which requires me to start
emacs executable from that directory.

How to solve this problem? (even sudo doesn't seems to help here?)

-- 
William


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] about permission setting for /var/tmp/portage/../work

[Rumen Yotov]

On (03/09/07 14:28) William Xu wrote:
> Hi, why the `work' subdir under /var/tmp/.. has this sort of permission
> setting: 
> 
> ,----
> | drwx------ 3 portage portage 80 Sep 3 10:43 work
> `----
> 
> This way, it seems rather difficult for a non-root user to access
> them. Currently I'm trying to debug emacs, which requires me to start
> emacs executable from that directory.
> 
> How to solve this problem? (even sudo doesn't seems to help here?)
> 
> -- 
> William
> 
> 
> -- 
> gentoo-user@gentoo.org mailing list
>
Hi,

May be because this directory is meant to be used by portage only.
IMHO that is so because of FEATURES="... userpriv ..." (please check the syntax).
Same must be valid for /usr/portage/distfiles (FAETURES= " ... parallel-fetch userpriv usersandbox...")
Why you need user access to this work-dir.
HTH. Rumen
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: about permission setting for /var/tmp/portage/../work

[William Xu]

Rumen Yotov <rumen@qrypto.org> writes:

> May be because this directory is meant to be used by portage only.

Since it's just a tmp dir, only allowing portage user to read seems too
strict.

> IMHO that is so because of FEATURES="... userpriv ..." (please check
> the syntax).  Same must be valid for /usr/portage/distfiles (FAETURES=
> " ... parallel-fetch userpriv usersandbox...")

Do you mean that I should add `userpriv' etc to FEATURES flag?  My
present setting is:

,----
| FEATURES="cvs parallel-fetch ccache keepwork"
`----

> Why you need user access to this work-dir.

Yes, it's a big weird that debugging emacs requires me running the
executable. 

,----[ /usr/share/emacs/23.0.0/etc/DEBUG ]
| ** When you debug Emacs with GDB, you should start it in the directory
| where the executable was made.  That directory has a .gdbinit file
| that defines various "user-defined" commands for debugging Emacs.
| (These commands are described below under "Examining Lisp object
| values" and "Debugging Emacs Redisplay problems".)
`----

-- 
William

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: about permission setting for /var/tmp/portage/../work

[Alan McKinnon]

On Monday 03 September 2007, William Xu wrote:
> Rumen Yotov <rumen@qrypto.org> writes:
> > May be because this directory is meant to be used by portage only.
>
> Since it's just a tmp dir, only allowing portage user to read seems
> too strict.

It's more than that. It's the portage *BUILD*DIRECTORY* (which just 
happens to be short-lived, not temp), that's where all your merges are 
built. Just like you don't want to give just anyone the ability to 
overwrite your binaries in /bin, you also don't want to give just 
anyone the ability to overwrite the same binaries while they are being 
built.

This is a very good and valid use of the healthy paranoia that unix 
admins are supposed to be born with.

You can start by investigating the various sandbox and userpriv FEATURES 
in make.conf (info in the portage man pages), or set up your sudoers to 
allow you to run commands as portage (I imagine you don't want to debug 
as root as permission bugs won't show up)

alan

-- 
Optimists say the glass is half full,
Pessimists say the glass is half empty,
Developers say wtf is the glass twice as big as it needs to be?

Alan McKinnon
alan at linuxholdings dot co dot za
+27 82, double three seven, one nine three five
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: about permission setting for /var/tmp/portage/../work

[William Xu]

Alan McKinnon <alan@linuxholdings.co.za> writes:

> It's more than that. It's the portage *BUILD*DIRECTORY* (which just 
> happens to be short-lived, not temp), that's where all your merges are 
> built. Just like you don't want to give just anyone the ability to 
> overwrite your binaries in /bin, you also don't want to give just 
> anyone the ability to overwrite the same binaries while they are being 
> built.

But I think giving group and others proper read and execute access is
safe enough. Like everybody can read things under /bin.

> You can start by investigating the various sandbox and userpriv FEATURES 
> in make.conf (info in the portage man pages), 

I doubt they could solve the issue.. 

,----[ ls -l . | grep work ]
| drwx------ 3 portage portage  80 Sep  3 10:43 work
`----

,----[ ls work -l ]
| drwxr-xr-x 21 root root 1432 Sep  3 10:50 emacs-unicode
`----

The problematic part is `work' directory. It better give normal users rx
access.

> or set up your sudoers to allow you to run commands as portage (I
> imagine you don't want to debug as root as permission bugs won't show
> up)

No, I don't want to run sudo here.

-- 
William

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: about permission setting for /var/tmp/portage/../work

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]

On Monday 03 September 2007 10:40:39 William Xu wrote:
> > It's more than that. It's the portage *BUILD*DIRECTORY* (which just
> > happens to be short-lived, not temp), that's where all your merges are
> > built. Just like you don't want to give just anyone the ability to
> > overwrite your binaries in /bin, you also don't want to give just
> > anyone the ability to overwrite the same binaries while they are being
> > built.
>
> But I think giving group and others proper read and execute access is
> safe enough. Like everybody can read things under /bin.

The problem is that during unpack and compile the permissions on the files in 
the work dir could be anything depending on the permissions inside the 
tarball the files might come from or depending on the build scripts (which 
may be run as root)...

E.g. if you get access to even enter the work dir during unpack and the 
unpacked files are world writeable then you can modify the build scripts 
before they get chmod'ed by portage at the end of the unpack and allow 
arbitrary code to be run later during the build as root...

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-user] Re: about permission setting for /var/tmp/portage/../work

[William Xu]

Bo Ørsted Andresen <bo.andresen@zlin.dk> writes:

> The problem is that during unpack and compile the permissions on the files in 
> the work dir could be anything depending on the permissions inside the 
> tarball the files might come from or depending on the build scripts (which 
> may be run as root)...

Ah, I see..Thanks ! 

-- 
William

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: about permission setting for /var/tmp/portage/../work

[Rumen Yotov]

Hi,
On (03/09/07 16:13) William Xu wrote:
> Rumen Yotov <rumen@qrypto.org> writes:
> 
> > May be because this directory is meant to be used by portage only.
> 
> Since it's just a tmp dir, only allowing portage user to read seems too
> strict.
> 
May be 'yes' but it's kind of security measure - so while compiling if
anything breaks you'll get an user shell not a root one (just guessing).
BTW anybody knows if gpg-signing of sources/eclasses is getting ready ?
> > IMHO that is so because of FEATURES="... userpriv ..." (please check
> > the syntax).  Same must be valid for /usr/portage/distfiles (FAETURES=
> > " ... parallel-fetch userpriv usersandbox...")
> 
> Do you mean that I should add `userpriv' etc to FEATURES flag?  My
> present setting is:
> 
> ,----
> | FEATURES="cvs parallel-fetch ccache keepwork"
> `----
> 
IIRC 'userpriv' uses portage uid to actually compile things, and root
only during final merge. But please check again (paludis user ;-)
> > Why you need user access to this work-dir.
> 
> Yes, it's a big weird that debugging emacs requires me running the
> executable. 
> 
> ,----[ /usr/share/emacs/23.0.0/etc/DEBUG ]
> | ** When you debug Emacs with GDB, you should start it in the directory
> | where the executable was made.  That directory has a .gdbinit file
> | that defines various "user-defined" commands for debugging Emacs.
> | (These commands are described below under "Examining Lisp object
> | values" and "Debugging Emacs Redisplay problems".)
> `----
> 
Could do the compilation in src|work directory in your HOME dir.
Or use step-by-step install:
ebuild /path/to/ebuild unpack|compile|install|qmerge|clean
check 'man ebuild' etc.
> -- 
> William
> 
> -- 
> gentoo-user@gentoo.org mailing list
> 
HTH. Rumen
-- 
gentoo-user@gentoo.org mailing list