Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #240245 > unrolled thread

Development permissions

Back to article view | Back to linux.debian.user

Contents

  Development permissions "Paul M. Foster" <paulf@quillandmouse.com> - 2021-09-22 05:20 +0200
    Re: Development permissions Charles Curley <charlescurley@charlescurley.com> - 2021-09-22 05:50 +0200
      Re: Development permissions "Paul M. Foster" <paulf@quillandmouse.com> - 2021-09-22 06:20 +0200
        Re: Development permissions David Christensen <dpchrist@holgerdanske.com> - 2021-09-22 06:30 +0200
        Re: Development permissions Felix Miata <mrmazda@earthlink.net> - 2021-09-22 06:40 +0200
        Re: Development permissions Anssi Saari <as@sci.fi> - 2021-09-22 09:30 +0200
    Re: Development permissions Georgi Naplatanov <gosho@oles.biz> - 2021-09-22 05:50 +0200
      Re: Development permissions "Paul M. Foster" <paulf@quillandmouse.com> - 2021-09-22 06:20 +0200
        Re: Development permissions Andrei POPESCU <andreimpopescu@gmail.com> - 2021-09-22 07:40 +0200
          Re: Development permissions Andrei POPESCU <andreimpopescu@gmail.com> - 2021-09-25 08:40 +0200
        Re: Development permissions Georgi Naplatanov <gosho@oles.biz> - 2021-09-22 07:40 +0200
        Re: Development permissions Tim Woodall <debianuser@woodall.me.uk> - 2021-09-22 10:30 +0200
    Re: Development permissions Reco <recoverym4n@enotuniq.net> - 2021-09-22 09:00 +0200
      Re: Development permissions Alex Mestiashvili <amestia@rsh2.donotuse.de> - 2021-09-24 10:30 +0200
        Re: Development permissions Reco <recoverym4n@enotuniq.net> - 2021-09-24 11:30 +0200
          Re: Development permissions Alex Mestiashvili <amestia@rsh2.donotuse.de> - 2021-09-24 11:50 +0200
            Re: Development permissions Reco <recoverym4n@enotuniq.net> - 2021-09-24 15:30 +0200
          Re: Development permissions <tomas@tuxteam.de> - 2021-09-24 14:10 +0200
            Re: Development permissions Reco <recoverym4n@enotuniq.net> - 2021-09-24 15:10 +0200
              Re: Development permissions Andy Smith <andy@strugglers.net> - 2021-09-24 15:50 +0200
              Re: Development permissions <tomas@tuxteam.de> - 2021-09-24 16:10 +0200
    Re: Development permissions Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2021-09-24 04:40 +0200

Page 1 of 2  [1] 2  Next page →

#240245 — Development permissions

Folks:

This is probably a stupid question for many of you, but I've been 
struggling with it since I started using Linux in 1996.

Say you have a directory in which there are development files. A number 
of users will be creating, deleting and modifying the files there. This 
is the type of situation which might have been common on old Unix 
university systems. (Users might be accessing files via Samba, NFS, or 
locally.)

Just to make this more concrete, assume the development tree is in 
/var/www/html/website.

Without setting directory and file permissions to 777, how do you allow 
the above? What combinations of groups, directory owners/permissions and 
file owners/permissions might make this possible?

Paul

[toc] | [next] | [standalone]

#240246

On Tue, 21 Sep 2021 23:09:41 -0400
"Paul M. Foster" <paulf@quillandmouse.com> wrote:

> Say you have a directory in which there are development files. A
> number of users will be creating, deleting and modifying the files
> there. This is the type of situation which might have been common on
> old Unix university systems. (Users might be accessing files via
> Samba, NFS, or locally.)
> 
> Just to make this more concrete, assume the development tree is in 
> /var/www/html/website.

This sounds like a development nightmare. It sounds like you are asking
people to step on each other's changes.

Much better to set up a version control system (git, e.g.), and let
everyone develop in their own spaces. People can code and test away
to their hearts' content. Wen they are satisfied, they check their
changes in. Then deployment is a matter of "git pull" (or equivalent) on
the working copy.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#240248

On 9/21/21 11:26 PM, Charles Curley wrote:
> On Tue, 21 Sep 2021 23:09:41 -0400
> "Paul M. Foster" <paulf@quillandmouse.com> wrote:
>
>> Say you have a directory in which there are development files. A
>> number of users will be creating, deleting and modifying the files
>> there. This is the type of situation which might have been common on
>> old Unix university systems. (Users might be accessing files via
>> Samba, NFS, or locally.)
>>
>> Just to make this more concrete, assume the development tree is in
>> /var/www/html/website.
> This sounds like a development nightmare. It sounds like you are asking
> people to step on each other's changes.
>
> Much better to set up a version control system (git, e.g.), and let
> everyone develop in their own spaces. People can code and test away
> to their hearts' content. Wen they are satisfied, they check their
> changes in. Then deployment is a matter of "git pull" (or equivalent) on
> the working copy.

Yeah, I use git in other contexts. In this particular instance, when 
these projects were created, git didn't exist. While I could implement 
it here, the other user is on a Mac. I've had experience trying to 
install "normal" software (like git) on a Mac (software not blessed by 
Apple), and it's not a pleasant experience. Additionally, the other 
developer uses Dreamweaver and doesn't do well with administrative tasks 
like "git push". I'm trying to make this as painless for her as 
possible. Under any other development circumstances, I would absolutely 
choose git.

However, as I said, this type of situation had to be common on old Unix 
systems, and they didn't have git. They had to have solved it some other 
way.

Paul

[toc] | [prev] | [next] | [standalone]

#240251

On 9/21/21 9:10 PM, Paul M. Foster wrote:

> Yeah, I use git in other contexts. In this particular instance, when 
> these projects were created, git didn't exist. While I could implement 
> it here, the other user is on a Mac. I've had experience trying to 
> install "normal" software (like git) on a Mac (software not blessed by 
> Apple), and it's not a pleasant experience.


You want MacPorts:

https://ports.macports.org/


Git is available:

https://ports.macports.org/port/git/


> Additionally, the other 
> developer uses Dreamweaver and doesn't do well with administrative tasks 
> like "git push". I'm trying to make this as painless for her as 
> possible. 

DreamWeaver supports Git:

https://helpx.adobe.com/dreamweaver/using/git-support.html


David

[toc] | [prev] | [next] | [standalone]

#240252

Paul M. Foster composed on 2021-09-22 00:10 (UTC-0400):

> However, as I said, this type of situation had to be common on old Unix 
> systems, and they didn't have git. They had to have solved it some other 
> way.
											
Have you investigated newgrp? I think this, or umask 002, or both, may be how we
coped with these things in the 1970s at university, and later on Xenix.
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

[toc] | [prev] | [next] | [standalone]

#240259

"Paul M. Foster" <paulf@quillandmouse.com> writes:

> However, as I said, this type of situation had to be common on old
> Unix systems, and they didn't have git. They had to have solved it
> some other way.

For me in the 90s the solution was what's mentioned. Group, permissions
and setgid bit. And everyone was told to set umask to 2. Worked OK for
an engineering team of around 10 people in a fairly homogenous Sun
Solaris environment.

[toc] | [prev] | [next] | [standalone]

#240247

On 9/22/21 06:09, Paul M. Foster wrote:
> Folks:
> 
> This is probably a stupid question for many of you, but I've been
> struggling with it since I started using Linux in 1996.
> 
> Say you have a directory in which there are development files. A number
> of users will be creating, deleting and modifying the files there. This
> is the type of situation which might have been common on old Unix
> university systems. (Users might be accessing files via Samba, NFS, or
> locally.)
> 
> Just to make this more concrete, assume the development tree is in
> /var/www/html/website.
> 
> Without setting directory and file permissions to 777, how do you allow
> the above? What combinations of groups, directory owners/permissions and
> file owners/permissions might make this possible?
> 

Hi Paul,

you can create a user group, add all developers to it and give this
group permissions to read and write to that particular folder
(/var/www/html/website).

If you need more granular permissions (e.g. several development teams)
then you can use ACLs (Access Control List).

Kind regards
Georgi

[toc] | [prev] | [next] | [standalone]

#240249

On 9/21/21 11:42 PM, Georgi Naplatanov wrote:
> On 9/22/21 06:09, Paul M. Foster wrote:
>> Folks:
>>
>> This is probably a stupid question for many of you, but I've been
>> struggling with it since I started using Linux in 1996.
>>
>> Say you have a directory in which there are development files. A number
>> of users will be creating, deleting and modifying the files there. This
>> is the type of situation which might have been common on old Unix
>> university systems. (Users might be accessing files via Samba, NFS, or
>> locally.)
>>
>> Just to make this more concrete, assume the development tree is in
>> /var/www/html/website.
>>
>> Without setting directory and file permissions to 777, how do you allow
>> the above? What combinations of groups, directory owners/permissions and
>> file owners/permissions might make this possible?
>>
> Hi Paul,
>
> you can create a user group, add all developers to it and give this
> group permissions to read and write to that particular folder
> (/var/www/html/website).
>
> If you need more granular permissions (e.g. several development teams)
> then you can use ACLs (Access Control List).
>
> Kind regards
> Georgi
>
This is more or less the solution I tried. However, when a user creates 
a file on this system, the permissions are (for example) paulf:paulf. 
This means that, despite the directory permissions, other users won't be 
able to modify the file normally (assuming a system umask of 022).

However, I did just read an excellent explanation of the setgid bit, 
which apparently, sets the GID of a created file to that of the 
directory, rather than the file's creator. This might work. I haven't 
tested it yet.

I've heard of ACLs, but never had the need to user or learn about this. 
I'm assuming that attending to ACL issues requires additional steps in 
the creation/editing/deletion of files?

Paul

[toc] | [prev] | [next] | [standalone]

#240254

[Multipart message — attachments visible in raw view] — view raw

On Mi, 22 sep 21, 00:15:48, Paul M. Foster wrote:
> 
> On 9/21/21 11:42 PM, Georgi Naplatanov wrote:
> > 
> > you can create a user group, add all developers to it and give this
> > group permissions to read and write to that particular folder
> > (/var/www/html/website).
> > 
> This is more or less the solution I tried. However, when a user creates a
> file on this system, the permissions are (for example) paulf:paulf. This
> means that, despite the directory permissions, other users won't be able to
> modify the file normally (assuming a system umask of 022).

Changing the umask to 002 is a must in this setup.
 
> However, I did just read an excellent explanation of the setgid bit, which
> apparently, sets the GID of a created file to that of the directory, rather
> than the file's creator. This might work. I haven't tested it yet.

It works, but it's a pain to setup, because it still needs umask 002 for 
all users and there are so many places to change the umask.

This might sound like heresy, but depending on your storage and 
permissions needs it is much easier to use a NTFS[1] partition as the 
backend, because you can enforce correct permissions and file/directory 
masks via mount options.

I'd be happy to learn about a comparable alternative.


[1] or even VFAT, but it's probably a bad idea to use that for anything 
but the few very specific cases where you can't use anything else.

Hope this helps,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#240336

[Multipart message — attachments visible in raw view] — view raw

On Mi, 22 sep 21, 08:37:42, Andrei POPESCU wrote:
> On Mi, 22 sep 21, 00:15:48, Paul M. Foster wrote:
>  
> > However, I did just read an excellent explanation of the setgid bit, which
> > apparently, sets the GID of a created file to that of the directory, rather
> > than the file's creator. This might work. I haven't tested it yet.
> 
> It works, but it's a pain to setup, because it still needs umask 002 for 
> all users and there are so many places to change the umask.
> 
> This might sound like heresy, but depending on your storage and 
> permissions needs it is much easier to use a NTFS[1] partition as the 
> backend, because you can enforce correct permissions and file/directory 
> masks via mount options.
> 
> I'd be happy to learn about a comparable alternative.

On a quick look bindfs (mentioned elsewhere in the thread) appears to be 
able to do this for any file system supported by the underlying 
operating system.

The performance might even be better compared to NTFS (which also needs 
FUSE for write access).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#240256

On 9/22/21 07:15, Paul M. Foster wrote:
> 
> On 9/21/21 11:42 PM, Georgi Naplatanov wrote:
>> On 9/22/21 06:09, Paul M. Foster wrote:
>>> Folks:
>>>
>>> This is probably a stupid question for many of you, but I've been
>>> struggling with it since I started using Linux in 1996.
>>>
>>> Say you have a directory in which there are development files. A number
>>> of users will be creating, deleting and modifying the files there. This
>>> is the type of situation which might have been common on old Unix
>>> university systems. (Users might be accessing files via Samba, NFS, or
>>> locally.)
>>>
>>> Just to make this more concrete, assume the development tree is in
>>> /var/www/html/website.
>>>
>>> Without setting directory and file permissions to 777, how do you allow
>>> the above? What combinations of groups, directory owners/permissions and
>>> file owners/permissions might make this possible?
>>>
>> Hi Paul,
>>
>> you can create a user group, add all developers to it and give this
>> group permissions to read and write to that particular folder
>> (/var/www/html/website).
>>
>> If you need more granular permissions (e.g. several development teams)
>> then you can use ACLs (Access Control List).
>>
>> Kind regards
>> Georgi
>>
> This is more or less the solution I tried. However, when a user creates
> a file on this system, the permissions are (for example) paulf:paulf.
> This means that, despite the directory permissions, other users won't be
> able to modify the file normally (assuming a system umask of 022).
> 
> However, I did just read an excellent explanation of the setgid bit,
> which apparently, sets the GID of a created file to that of the
> directory, rather than the file's creator. This might work. I haven't
> tested it yet.
> 
> I've heard of ACLs, but never had the need to user or learn about this.
> I'm assuming that attending to ACL issues requires additional steps in
> the creation/editing/deletion of files?
> 

I have not used ACLs either. I heard about them about 15 or more years
ago and it required parameter (as I can remember) during file system
creation. I don't know what is the situation now.

Kind regards
Georgi

[toc] | [prev] | [next] | [standalone]

#240262

On Wed, 22 Sep 2021, Paul M. Foster wrote:

>
> This is more or less the solution I tried. However, when a user creates a 
> file on this system, the permissions are (for example) paulf:paulf. This 
> means that, despite the directory permissions, other users won't be able to 
> modify the file normally (assuming a system umask of 022).
>
> However, I did just read an excellent explanation of the setgid bit, which 
> apparently, sets the GID of a created file to that of the directory, rather 
> than the file's creator. This might work. I haven't tested it yet.
>
> I've heard of ACLs, but never had the need to user or learn about this. I'm 
> assuming that attending to ACL issues requires additional steps in the 
> creation/editing/deletion of files?
>

chmod 2775 on the directory and make the group of the directory a group
that all of the users belong to.

(sorry, I'm really old school and I don't know what the "modern"
equivalent is for that without going to the man page, the flags are
drwxrwsr-x)

Then any files created in that directory should get the correct group
for everybody to have access.

You'll have to ensure everybody has the correct umask (002).

Tim.

[toc] | [prev] | [next] | [standalone]

#240258

	Hi.

On Tue, Sep 21, 2021 at 11:09:41PM -0400, Paul M. Foster wrote:
> Without setting directory and file permissions to 777, how do you
> allow the above? What combinations of groups, directory
> owners/permissions and file owners/permissions might make this
> possible?

Solution #1:

1) Make a group, add users to it.
2) Chgrp directory to the group from step 1.
3) Set directory permissions to 2770 (i.e. you will need setgid on
directory), or 2775 if you need world-readable directory.
4) Ensure users' umask is set to 0007.


Solution #2:

Set ACL to u:<user>:rwx on a directory, and make sure it made to the
"default" set of permissions (i.e. you'll need setfacl -d).

Reco

[toc] | [prev] | [next] | [standalone]

#240296

On 9/22/21 8:53 AM, Reco wrote:
> 	Hi.
> 
> On Tue, Sep 21, 2021 at 11:09:41PM -0400, Paul M. Foster wrote:
>> Without setting directory and file permissions to 777, how do you
>> allow the above? What combinations of groups, directory
>> owners/permissions and file owners/permissions might make this
>> possible?
> 
> Solution #1:
> 
> 1) Make a group, add users to it.
> 2) Chgrp directory to the group from step 1.
> 3) Set directory permissions to 2770 (i.e. you will need setgid on
> directory), or 2775 if you need world-readable directory.
> 4) Ensure users' umask is set to 0007.
> 
> 
> Solution #2:
> 
> Set ACL to u:<user>:rwx on a directory, and make sure it made to the
> "default" set of permissions (i.e. you'll need setfacl -d).
> 
> Reco
> 

In addition to umask and acl, there is also a FUSE based bindfs.

[toc] | [prev] | [next] | [standalone]

#240298

	Hi.

On Fri, Sep 24, 2021 at 10:22:00AM +0200, Alex Mestiashvili wrote:
> On 9/22/21 8:53 AM, Reco wrote:
> > 	Hi.
> > 
> > On Tue, Sep 21, 2021 at 11:09:41PM -0400, Paul M. Foster wrote:
> > > Without setting directory and file permissions to 777, how do you
> > > allow the above? What combinations of groups, directory
> > > owners/permissions and file owners/permissions might make this
> > > possible?
> > 
> > Solution #1:
> > 
> > 1) Make a group, add users to it.
> > 2) Chgrp directory to the group from step 1.
> > 3) Set directory permissions to 2770 (i.e. you will need setgid on
> > directory), or 2775 if you need world-readable directory.
> > 4) Ensure users' umask is set to 0007.
> > 
> > 
> > Solution #2:
> > 
> > Set ACL to u:<user>:rwx on a directory, and make sure it made to the
> > "default" set of permissions (i.e. you'll need setfacl -d).
> 
> In addition to umask and acl, there is also a FUSE based bindfs.

FUSE = slow + CPU wastage

Using a filesystem the way it was intended is much cleaner solution.

Reco

[toc] | [prev] | [next] | [standalone]

#240299

On 9/24/21 11:27 AM, Reco wrote:
> 	Hi.
> 
> On Fri, Sep 24, 2021 at 10:22:00AM +0200, Alex Mestiashvili wrote:
>> On 9/22/21 8:53 AM, Reco wrote:
>>> 	Hi.
>>>
>>> On Tue, Sep 21, 2021 at 11:09:41PM -0400, Paul M. Foster wrote:
>>>> Without setting directory and file permissions to 777, how do you
>>>> allow the above? What combinations of groups, directory
>>>> owners/permissions and file owners/permissions might make this
>>>> possible?
>>>
>>> Solution #1:
>>>
>>> 1) Make a group, add users to it.
>>> 2) Chgrp directory to the group from step 1.
>>> 3) Set directory permissions to 2770 (i.e. you will need setgid on
>>> directory), or 2775 if you need world-readable directory.
>>> 4) Ensure users' umask is set to 0007.
>>>
>>>
>>> Solution #2:
>>>
>>> Set ACL to u:<user>:rwx on a directory, and make sure it made to the
>>> "default" set of permissions (i.e. you'll need setfacl -d).
>>
>> In addition to umask and acl, there is also a FUSE based bindfs.
> 
> FUSE = slow + CPU wastage

Well, fast enough and CPU time is cheap ;)
Setting umask might be insecure/problematic for non-unix people.
Not every filesystem support ACL.
Bindfs is just another useful tool...

> 
> Using a filesystem the way it was intended is much cleaner solution.

ACL is a workaround for the "intended unix permissions" isn't?

Old unix concepts from 1970 don't really meet expectation of apple fan 
boys and people used to rich NTFS permissions...

> 
> Reco
> 

[toc] | [prev] | [next] | [standalone]

#240304

	Hi.

On Fri, Sep 24, 2021 at 11:47:20AM +0200, Alex Mestiashvili wrote:
> On 9/24/21 11:27 AM, Reco wrote:
> > 	Hi.
> > 
> > On Fri, Sep 24, 2021 at 10:22:00AM +0200, Alex Mestiashvili wrote:
> > > On 9/22/21 8:53 AM, Reco wrote:
> > > > 	Hi.
> > > > 
> > > > On Tue, Sep 21, 2021 at 11:09:41PM -0400, Paul M. Foster wrote:
> > > > > Without setting directory and file permissions to 777, how do you
> > > > > allow the above? What combinations of groups, directory
> > > > > owners/permissions and file owners/permissions might make this
> > > > > possible?
> > > > 
> > > > Solution #1:
> > > > 
> > > > 1) Make a group, add users to it.
> > > > 2) Chgrp directory to the group from step 1.
> > > > 3) Set directory permissions to 2770 (i.e. you will need setgid on
> > > > directory), or 2775 if you need world-readable directory.
> > > > 4) Ensure users' umask is set to 0007.
> > > > 
> > > > 
> > > > Solution #2:
> > > > 
> > > > Set ACL to u:<user>:rwx on a directory, and make sure it made to the
> > > > "default" set of permissions (i.e. you'll need setfacl -d).
> > > 
> > > In addition to umask and acl, there is also a FUSE based bindfs.
> > 
> > FUSE = slow + CPU wastage
> 
> Well, fast enough and CPU time is cheap ;)

An old argument. How exactly I can replace CPU on my Raspberry Pi 1B
which is still in service and doing its job?


> Setting umask might be insecure/problematic for non-unix people.
> Not every filesystem support ACL.

Every filesystem that's worthy of such title does support ACL.
Inperfect filesystems do not indeed, but replacing a filesystem is much
easier than replacing a CPU.


> Bindfs is just another useful tool...

That's something I agree with. Every tool has its purpose, and surely
bindfs has one too. But using a tool outside of its purpose instantly
transforms a tool to a kludge.


> > Using a filesystem the way it was intended is much cleaner solution.
> ACL is a workaround for the "intended unix permissions" isn't?

That's one option about it. Another one is ACL is an evolution of POSIX
filesystem permissions.
Whichever you prefer, of course.

Reco

[toc] | [prev] | [next] | [standalone]

#240302

[Multipart message — attachments visible in raw view] — view raw

On Fri, Sep 24, 2021 at 12:27:56PM +0300, Reco wrote:

[...]

> FUSE = slow + CPU wastage
> 
> Using a filesystem the way it was intended is much cleaner solution.

On the flip side, using an in-kernel file system is running code
in kernel space which was conceived and written in happier times.

Back then you could more or less safely assume that a file system
image wasn't out to kill you. These days, though...

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#240303

	Hi.

On Fri, Sep 24, 2021 at 01:59:58PM +0200, tomas@tuxteam.de wrote:
> On Fri, Sep 24, 2021 at 12:27:56PM +0300, Reco wrote:
> 
> [...]
> 
> > FUSE = slow + CPU wastage
> > 
> > Using a filesystem the way it was intended is much cleaner solution.
> 
> On the flip side, using an in-kernel file system is running code
> in kernel space which was conceived and written in happier times.

I cannot see what's exactly wrong with ext4 these days.
Unless you have something against IBM/RH that is.

And by using FUSE one does not get a magical safeguard against kernel
panics and processes in D-state.


> Back then you could more or less safely assume that a file system
> image wasn't out to kill you. These days, though...

Oh. Citation needed. Curious minds want to know.
How exactly one can produce a filesystem image that tries to get you?
Just in case, I'm asking out of mere curiosity, not with an intent on
using said image on somebody ;)

Reco

[toc] | [prev] | [next] | [standalone]

#240308

Hello,

On Fri, Sep 24, 2021 at 04:06:10PM +0300, Reco wrote:
> On Fri, Sep 24, 2021 at 01:59:58PM +0200, tomas@tuxteam.de wrote:
> > Back then you could more or less safely assume that a file system
> > image wasn't out to kill you. These days, though...
> 
> Oh. Citation needed. Curious minds want to know.

I've repeatedly read kernel developers say that there are no safety
guarantees about mounting a filesystem that someone else has made.
In this article, Theodore TS'o (the primary developer of ext*) is
quoted as saying that ext4 and XFS currently aren't safe in that
regard:

    https://lwn.net/Articles/796687/

> How exactly one can produce a filesystem image that tries to get you?

You would craft invalid metadata that caused bad things to happen
when it's mounted. Just because the kernel can't make such metadata
itself doesn't mean that an attacker can't write it to an image.

The article is about a new filesystem, where it was pointed out that
it would be trivial to craft an image that crashed the kernel. That
was considered a bug and fixed, but existing Linux filesystem
developers admit that there are similar bugs in incredibly popular
existing filesystems on Linux, so to demand that a new filesystem
didn't have that problem would be a double standard. Others
preferred to see it as standards being raised.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web