On 01/19/2018 08:14 PM, William Hubbs wrote:
>>
>> Why not? Since /var/lib is root:root and mode 755, we can create
>> /var/lib/foo while running --as=root (the default). Then afterwards,
>> anything beneath /var/lib/foo would need to be created "--as" the owner
>> of that directory.
>
> That woul
On Fri, Jan 19, 2018 at 07:53:06PM -0500, Michael Orlitzky wrote:
> On 01/19/2018 07:16 PM, William Hubbs wrote:
> >
> > It looks like we can't use your --as suggestion if we want to be
> > able to create paths in /var/lib and /var/spool that are owned by
> > non-privileged users because of the pe
On 01/19/2018 07:16 PM, William Hubbs wrote:
>
> It looks like we can't use your --as suggestion if we want to be
> able to create paths in /var/lib and /var/spool that are owned by
> non-privileged users because of the permissions on those paths. It is
> possible that service scripts are doing th
On Thu, Jan 18, 2018 at 07:19:59PM -0500, Michael Orlitzky wrote:
> Not at all. I'm working this out as I go, so better to speak up if
> something looks fishy.
>
> There are a few risks that I see with the first approach...
>
>
> Risk #1: From what I can tell, the current implementation of check
On 01/17/2018 12:14 PM, William Hubbs wrote:
>>
>> 1. I could create /run/foo with owner "foo", and then create
>>/run/foo/bar with owner "foo". That can be done without modifying
>>existing permissions, but it's not safe, because you wind up working
>>as root in the directory /run/foo
On Wed, Jan 17, 2018 at 10:41:21AM -0500, Michael Orlitzky wrote:
> If I want to create /run/foo and /run/foo/bar, both owned by the "foo"
> user, how would I do it using newpath?
>
> 1. I could create /run/foo with owner "foo", and then create
>/run/foo/bar with owner "foo". That can be done
On 01/17/2018 10:21 AM, William Hubbs wrote:
>
> For both A and B above I think you mean owner/group/permissions right?
Yep.
>> 2. It should have a flag (say, --as=[:group]) to make it run as
>> an unprivileged user. Basically a portable "su -c".
>
> I'm not following why I need this.
>
On Sat, Jan 13, 2018 at 03:48:10PM -0500, Michael Orlitzky wrote:
> On 01/10/2018 04:54 PM, William Hubbs wrote:
> >
> > What are we saying newpath should do differently than checkpath if I
> > go this route?
>
> I think this covers everything that we've talked about:
>
> 1. It should refuse to
On 01/10/2018 04:54 PM, William Hubbs wrote:
>
> What are we saying newpath should do differently than checkpath if I
> go this route?
I think this covers everything that we've talked about:
1. It should refuse to modify existing paths.
1.a. If newpath is called on an existing path, and if
On 01/10/2018 01:17 PM, Kristian Fiskerstrand wrote:
>>
>> (I didn't realize at the time that the OpenRC fix still contained a race
>> condition.)
>
> This was mentioned already in https://bugs.gentoo.org/540006#c15
>
So it is =)
I took the RESOLVED FIXED for granted when I reported the tmpfile
On 01/10/2018 05:18 PM, James Le Cuirot wrote:
>
> The init script used to call chown/chmod -R, which is
> obviously bad. I've compromised by only calling these on the
> directories themselves (ignoring symlinks). I believe this is safe
> because it's not possible to create hard linked directories
On Tue, 9 Jan 2018 18:07:41 -0600
William Hubbs wrote:
> All,
>
> please take a look at the following issue.
>
> https://github.com/openrc/openrc/issues/195
>
> The first part of the fix is committed to master as shown on the issue;
> checkpath should *never* follow symbolic links when changin
On Wed, Jan 10, 2018 at 03:25:55PM -0500, Michael Orlitzky wrote:
> On 01/10/2018 01:04 PM, William Hubbs wrote:
> > On Tue, Jan 09, 2018 at 08:19:24PM -0500, Michael Orlitzky wrote:
> >
> >> Ultimately, it's not safe to chown/chmod/setfacl/whatever in a directory
> >> that is not writable only by
On 01/10/2018 01:04 PM, William Hubbs wrote:
> On Tue, Jan 09, 2018 at 08:19:24PM -0500, Michael Orlitzky wrote:
>
>> Ultimately, it's not safe to chown/chmod/setfacl/whatever in a directory
>> that is not writable only by yourself and root.
>
> Let me try to phrase this another way.
>
> If the
On 01/10/2018 02:19 AM, Michael Orlitzky wrote:
> On 01/09/2018 07:07 PM, William Hubbs wrote
>>
>> However, I'm not sure how to deal with the hard link issue in a way that
>> will not break service scripts.
>>
>
> Systemd mitigates this by enabling the fs.protected_hardlinks sysctl by
> default,
On Tue, Jan 09, 2018 at 08:19:24PM -0500, Michael Orlitzky wrote:
*snip*
> Ultimately, it's not safe to chown/chmod/setfacl/whatever in a directory
> that is not writable only by yourself and root.
Let me try to phrase this another way.
If the directory we are in is not owned by us or root and
On 01/09/2018 07:07 PM, William Hubbs wrote
>
> However, I'm not sure how to deal with the hard link issue in a way that
> will not break service scripts.
>
Systemd mitigates this by enabling the fs.protected_hardlinks sysctl by
default, but they have the liberty of requiring a relatively new Li
All,
please take a look at the following issue.
https://github.com/openrc/openrc/issues/195
The first part of the fix is committed to master as shown on the issue;
checkpath should *never* follow symbolic links when changing ownership,
so I have moved to the lchown call instead of chown.
Howeve
18 matches
Mail list logo
